Re: [WSG] IE 6 Horizontal Menu Shift
On Feb 20, 2007, at 1:03 PM, Sarah Peeke (XERT) wrote: When you click on a link in Win XP IE6 the whole list moves horizontally. I've tried lots of things, but can't seem to find the bug. URL: <http://www.xert.com.au/mytest/> CSS: <http://www.xert.com.au/mytest/mytest.css> % margins bug <http://www.positioniseverything.net/explorer/percentages.html> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] CSS and non-standard properties
On Feb 14, 2007, at 10:13 AM, Ben Buchanan wrote: I don't immediately see the benefit to the UA developers using a custom rule... Why not just use the real thing? I can only assume there's something about the process that I'm not aware of. Take border-radius. When it was first implemented in Gecko, centuries ago, they used (and still use): -moz-border-radius-topleft that was more or less what a then draft was suggesting. Fast-forward, WebKit uses -webkit-border-top-left-radius according to more current drafts. The advantage of using vendor prefixes for experimental properties is obvious. Once a CSS3 draft enters a more stable stage (last-call) or similar, the vendor can always alias their implemented name to the real thing, internally. Who knows what the real property name will be ? Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sending correct MYME-TYPE and content
On Feb 11, 2007, at 3:33 AM, Pierre-Henri Lavigne wrote: Regards to http://www.w3.org/MarkUp/2004/xhtml-faq#ie I just discovered, I was just wondering if we could use : [snip code] <http://keystonewebsites.com/articles/mime_type.php> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Clearing floats with overflow
Katrina wrote: If children of a container are floated, as far as I understand, they are then taken out of normal flow and the container collapses. Now, if overflow:hidden is applied to the parent container, then the height of the parent container is adjusted to include the heights of the floated children. That is correct. This is where I get lost: I understand overflow to describe what should happen to children/content that 'overflows' the parent container. Since the floats are out of normal flow, how come overflow applies at all? Have I misunderstood the basic concept of floats or overflow or something else altogether? Are the children now back into normal flow or has the container been taken out of normal flow or what is going on? No, floated children of a container with overflow set to 'scroll', 'hidden' or 'auto' are not put back in the normal flow. You should have a look at 9.4.1: Block Formatting Contexts [1] Essentially, an element with overflow set to e.g. 'hidden' establishes a new block formatting context. Very much simplified, that element creates it's own little box that contains everything within it, and nothing can escape out of that box. [1] <http://www.w3.org/TR/CSS21/visuren.html#q15> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Noobie: Padding-top, padding-bottom
Dan Dorman wrote: Firefox, Opera, and IE don't seem to apply top or bottom margins or padding to inline elements Each of these browsers does apply padding to inline elements (OK, IE sometimes get it wrong... nothing new there). But applying padding to an inline element doesn't affect the line-box(es). Margin-top and margin-bottom have no effect on inline, non-replaced elements. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Form Widgets
1. Form controls are UI widgets more than html elements. 2. CSS 2.1 doesn't define which properties apply to form controls <http://www.w3.org/TR/CSS21/conform.html#conformance> 3. Most form controls can't really be defined/described in terms of CSS 2.1. 4. many users prefer form controls that can not be styled (OS specific). I had a huge amount of feedback in that sense when I developed my alternative form controls package for Fx Mac [1]. The same can be seen through Camino feedback mail. Barney Carroll wrote: The reason WebKit apps didn't allow this was because they were developed at a time when standards awareness was very low, That is not true. Rather, something like: nobody bothered to spend time developing an implementation that allows author styling. and the functionality of forms is something extremely important to convey - something that if styled wrong might easily confuse the user. But that is certainly true. I recently came across an 'award wining theme' for a well-known blogging software package. Thing was/is using one of those fancy Image replacement methods for submit buttons. Unreadable grey on grey text in mouse type. Barely noticeable difference between page background and widget. No text label. I prefer the un-style-able widgets in my browser (Camino). Firefox 3 Mac will have native form controls. Those will be more or less sensitive to author styling. A user preference to allow/disallow that author styling is in the pipeline (similar to what Opera Mac has). [1] <http://emps.l-c-n.com/articles/94/widgets-for-firefox> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Bizarre IE Float/Clearing Bug
On Feb 1, 2007, at 9:28 AM, Mordechai Peller wrote: a1b1div> Thanks, but to clarify, the posted code isn't the code from the page, rather it's a generic example to illustrate the bug. The actual code is in the following form: so the alternative I had in mind is: But let's say the markup is as follows: a1b1 a2b2 a3b3 in which case there is no alternative which isn't much less semantic (e.g., giving each pair its own dl). What would suggest then? I don't think the good-people-at-MS (tm) ever read 9.5.1 in CSS 2.1 [1], and particularly the 5th point in the ordered list. Both IE 6 and IE 7 are completely broken on that. (usual...) Solutions for both your form and your definition list: float only the label / the . I use that quite frequently and that works reasonably well in iExploder. In some cases the parent container, e.g. the may need a 'haslayout' trigger. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Styling form elements in Safari
On Jan 31, 2007, at 12:08 PM, TomGou wrote: Am I correct in assuming there isn't a way to style an input of type submit in Safari to match what I've styled that shows in Firefox and Netscape? button text Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Remove 3D Border Effect from Firefox Tables
It is always a good idea to check the CSS-discuss wiki <http://css-discuss.incutio.com/?page=StyleInEmail> might have enough links, tips and tricks to do what you want. (and you can always update it...) Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Styling a Code Listing
On Jan 26, 2007, at 1:12 AM, Thierry Koblentz wrote: I'd appreciate any comment that would help me improve this article: http://www.tjkdesign.com/articles/how_to_style_a_code_listing.asp Why the need for a background image ? <http://dev.l-c-n.com/_temp/listing.html> (the div is there to give 'layout' for iExploder if needed, might be useful for decoration as well) Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Growing height and changing colspan when using display none/block in FF and Saf
On Jan 16, 2007, at 6:47 AM, Ron Jonk wrote:
I display and hide a row. When clicking on a link I swap the class
of the row from .show {display:block} to .hide{display:none}.
In IE it works OK but when I display the hidden row in safari and
Firefox the whole row that I display again has the width of the
first cell of the row above and the space between the hidden row
and the row above grows.
You need to switch between display:none and display:table-row (the
default display value for ).
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Background image rendering
On Dec 2, 2006, at 4:50 AM, Tom Livingston wrote:
html, body{ position:relative; font:100%/1.2 Verdana, Arial,
Helvetica,
sans-serif; background-color:#fff; color:#888; height:100%; padding:0;
margin:0;}
html#home{ background:url("../images/home_bgimage.gif") 50% 0 no-
repeat;}
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; id="home">
The background-color on body is covering the background-image on html.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Background image rendering
On Nov 27, 2006, at 11:14 PM, Nick Fitzsimons wrote: Sounds logical. However, I am using IDs on the body to give, among other things, different bg images to site sections. Can I give the HTML element an ID instead? I just never heard of doing this type of thing to that element. Afraid not, the HTML element can only have lang and dir attributes: <http://www.w3.org/TR/html4/struct/global.html#edef-HTML> This only applies to HTML 4.01 and XHTML 1.1. XHTML 1.0 allows for the id attribute on HTML. AvK has some details and references <http://annevankesteren.nl/2003/08/html-id> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] moz-inline-box or block
On Nov 23, 2006, at 7:13 PM, Keryx webb wrote:
Alt. 1:
elem {
display: -moz-inline-block;
display: inline-block; /* some say this one is really buggy */
}
Alt. 2:
elem {
display: -moz-inline-block;
display: inline-box; /* not intended for (X)HTML, but XUL */
}
Alt. 3:
elem {
display: table-cell; /* Could give me the desired effect */
display: inline-block;
}
Option 1 is *really* buggy on Gecko 1.7 and Gecko 1.8.x (Fx 1.0 to 2.0)
For option 2 I guess you mean
elem {
display: -moz-inline-box;
display: inline-block; /* not intended for (X)HTML, but XUL */
}
Indeed not intended for X)HTML, no guarantees it will be supported
(in HTML) in the future. Some people @mozilla would like to remove
it, except for form controls.
Option 3 will give you the best results.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] what's causing ie7 to ignore the "valid div rules?"
On Nov 22, 2006, at 4:08 PM, Dwain Alford wrote:
http://www.alforddesigngroup.com/
hey, it's 0100hrs where i am; i've been at this for some time now.
sorry
for the brain fart.
dwain
On 11/22/06, Matthew Pennell <[EMAIL PROTECTED]> wrote:
On 11/22/06, Dwain Alford <[EMAIL PROTECTED]> wrote:
>
> in ie7 the "valid" div hangs over the "container" div. all other
> browsers that i can check render the div inside the container
with a 1em
> margin. what do i need to do to fix this so ie7 will render
properly?
Is your IE 7 window narrower than in other browsers ?
The only problem I can see on that page are the 3 icons in the #valid
div.
That is too narrow to contain the images in *all* my browsers {1],
end the images are pushed out.
Correct behaviour, small human error.
Add this to your #valid rule block: background:yellow;
then resize your window in different browsers. You'll see.
IE 6 is saved by its own stupidity (expands the container to match
the content).
[1] Firefox 2.0, Safari, Opera 9, IE mac, IE 7 windows,...
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: WebKit: '-khtml' ?!! (Was: Re: [WSG] Safari DOM inspector)
On Nov 18, 2006, at 8:23 AM, James Ellis wrote: If you run recent version of Konquerer you get a pretty good realisation of what Safari will render a site as - all you have to do us run a Linux box or if you don't want to do that run up a KDE distro Live CD like Kubuntu. There are quite a few bugs in Safari that don't show up in Konqueror, and vice-versa. example: E:last-child is completely br0ken in Safari but works fine in Konqueror. Mac users can install the whole KDE on top of OS X via the Fink project and run it side by side. Compiling took a little over 24 hours on my PowerBook. It runs wonderfully well. It's the right way to do vendor specific extensions to CSS e.g -moz- blah and -khtml-blah etc etc. So ,for instance, Gecko is supposed to ignore everything vendor specific and non -moz-*. I don't think IE has any -ie-* rules, -opera-* maybe ? dunno. For Opera: -o-* Afaik, MSIE didn't have any, up till now. I heard about -mso-, but not seen. Anyway, most of those vendor only extensions are for internal use only [*], and shouldn't be used in an author stylesheet. Except for a few that are implementations of css3 drafts, such as: - webkit-border-radius or -moz-border-radius, to name one that is relatively stable. Even then, use only on an experimental basis, the implementation could change, etc. [*] or for XUL in Gecko's case. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
On Nov 16, 2006, at 9:07 PM, Barney Carroll wrote: Thanks for the info - I downloaded the OmniWeb 5.5.1 trial (gorgeous tabs system, incidentally); and it renders the page in question, with bug, exactly like the current release of Safari. Excellent (for my purposes). Possible. Omniweb 5.5.1 doesn't use the latest of the latest version of Webkit, but a snapshot form June or July 2006, iirc. However I see no sign of a WebInspector... It's not immediately apparent from OmniWeb's interface, Omni don't seem to think it's worth mentioning in their list of fancy features, and a site search for 'inspector' only finds instances of it in their other products (all irrelevant in this case). You have to turn it on :-) Close Omniweb and type the following (exactly !) in a new terminal window: defaults write com.omnigroup.OmniWeb5 WebKitDeveloperExtras -bool true (one line, watch out for wrapping). And you'll see that it is still missing some panes. (to keep it ore on topic, aka debugging tools) One feature is sorely missing in WebKits inspector: the ability to live edit properties and values for an element. I use that the whole time with Gecko's DomInspector. IE's toolbar also has this option. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
On Nov 16, 2006, at 7:48 PM, Barney Carroll wrote: Today I found this fantastic utility [http://webkit.org/]. WebKit is a terribly vague name, but I suppose 'the WebKit nightly build' about sums it up. I fired it up and went to look at my bug in question and got so distracted by its fantastic inspection frames (metrics! woo!) that it took me a while to notice that the bug in question had disappeared. WebKit is the rendering engine behind Safari. What you have downloaded is a nightly build of what will be Safari 3.0 in Spring 2007. And yes, Safari 3.0 will have a WebInspector, just as OmniWeb 5.5 already has one - not a surpirse, as it uses the same WebKit rendering engine. And it is very possible that a bug you see in Safari 1.3/2.0 doesn't exist anymore in those nightly WebKit builds. One would hope that some bugs get fixed, after all... Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] display: table causing Gecko based browsers extra space for
On Nov 1, 2006, at 10:22 AM, Tee G.Peng wrote: Thierry suggested adding display: table or inline-table in dd and dt. 'Inline table' doesn't solves the Safari's problem for (1) but the 'table' does, however it resulting bigger spacing (top and bottom) in Gecko based browsers. playing with margins or paddings doesn't fix the problem. Any solution for this? One thing though, the 'display:table' only work when declared in both dt and dd. Without 'display:table' http://new.marinersq.com/html/aerobics_test.html With 'display:table' http://new.marinersq.com/html/aerobics.html Gecko (Firefox 2.0) is doing something strange with that display: table, as if it inserts an extra table-row before the link, inside the . When I check that on a recent Gecko trunk build, that doesn't happen (means: a bug has been fixed). As for Safari, it does also has a bug there (also fixed in recent nightly builds). Instead of using 'display:table' to establish a block formatting context, try using 'overflow:hidden'. That doesn't cause any problems in any modern browser here (Opera, Safari, gecko). You might want to hide that from IE 6 and maybe 7. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible Multi-Column List
On Oct 26, 2006, at 7:26 PM, Sarah Peeke (XERT) wrote: The methods I describe in this article use ems for positioning, not pixels: http://www.alistapart.com/articles/multicolumnlists/ My favorite method is the last (#6). Have you found that it doesn't survive cross-browser? I'd be interested in your findings. I saw your example 6, and it looks great. I maybe nitpicking but the columns don't line up in Safari 2.0.4 or Opera 9.0.2 Mac. I know they've got a small audience generally, but I'm hoping to find something more x-browser if possible. Do you know a workaround for this? Unfortunately, there are no workarounds. It all depends on how the browser decides to round off the numbers: assume the computed height of one is 2.1em (font-size/line-height/padding); this might compute to 33.6 px (@font-size=16px). Then you have to take the total computed height of one column (number of by 2.3em). Depending on how browsers round the numbers of, you end up with a few (screen) px difference. How do you slice pixels on screen ? All browser use different methods with Gecko being one of the more 'exact'. In the case above, assuming five in a column, Gecko will compute the following numbers: 33/34/33/34/33 (equals 167px, where as the compute height of the column is 168px). Other browsers will round off the height of each to 33px but make the total computed height 168px. See where we are going ? Note: I simplify slightly above. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Forget about Opera and Mac (and Windows Vista) ??
On Oct 26, 2006, at 8:09 AM, Taco Fleur wrote: I thought I'd post this question as a separate item, as it probably got lost in my previous post. Should I be thinking about fixing up the issues in Opera and on the Mac or just say "tough luck!" All pages validate www.pacificfox.com.au, and I have no idea what is causing the issues, mainly with the 4 top buttons. http://www.browsercam.com/public.aspx?proj_id=294234 7966358.JPG (Explorer 5.2 on Mac) 7966370.JPG (Opera) 7966382.JPG (Opera) The issues with IE 5 Mac are dead easy to fix. The around those 4 buttons is floated, but you don't specify a width for it. Remember that IE 5 Mac is a CSS 2.0 browser, and that a width is **required** on floated boxes. <http://www.l-c-n.com/IE5tests/float2misc/> <http://www.w3.org/TR/REC-CSS2/visuren.html#floats> The Opera issues are puzzling. And then there is http://www.browsercam.com/public.aspx?proj_id=294540 Internet Explorer V7 I have no experience with IE7, is it maybe still in Beta, is that why it is displaying this badly? The pages validate properly. IE 7 has been released recently and will be pushed through software update soon. It doesn't look as bad as on your screenshots. <http://emps.l-c-n.com/bm/pacificfox.png> The main issue seem with those grey headings and the more button. div.h3 seems to have a width of 0 (zero). Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] tabindex doesn't work
On Oct 25, 2006, at 5:25 AM, Tee G. Peng wrote: Yes I did. I have the 'enable tab browsing' selected both in Safari and Firefox. hmmm, embarrassing! I guess the problem is I don't know exactly how to 'tab'. Ok how do you do that in Mac? For both Firefox and Safari: Go System Preferences (from the Apple Menu) > Keyboard and Mouse > Keyboard Shortcuts and enable Full Keyboard Access (--> All Controls). Additional for Safari: Open Safari > preferences > Advanced tab and check the second textbox. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] link:active = keyboard focus?
On Oct 23, 2006, at 4:34 PM, Andreas Boehmer [Addictive Media] wrote: This is real strange: I am trying to change the style of a link when the user tabs onto it with the keyboard. I assumed that the active pseudo class would do the job, but maybe I am wrong? Here the code to my example: http://www.prototype.net.au/test.html I would love for the link to turn red when the user tabs onto it. But Firefox doesn't do it at all and IE6 does it if I first tab onto it and then move the mouse over it. (?!) Am I overestimating the abilities of the active pseudo class? You should use the :focus pseudo-class in this case. a:active points to the moment you click the link, or hit the return key if you use the keyboard (activate the link). IE win is broken here. It doesn't recognise the a:focus pseudo-class, and treats a:active as if it were a:focus instead, and even then... Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE6 -> IE7
Looks like that thing has been released <http://neowin.net/index.php?act=view&id=35665> Time to lock one of my VirtualMachines out of software update to keep IE 6, and have the other one allowed to proceed, me thinks. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Pure CSS dropdown Menu, take II
On Oct 17, 2006, at 2:21 AM, Thierry Koblentz wrote: I followed all suggestions made after I published the first demo and came up with this... Demo: http://www.tjkdesign.com/articles/keyboard_friendly_dropdown_menu/ Article: http://www.tjkdesign.com/articles/Pure_CSS_Dropdown_Menus.asp Keyboard users can go from one top level item to the next without having to go through the nested links (the enter key toggles the sub-menus). Regarding pointing devices; I went with vertical sub-menus rather than horizontal ones (avoiding diagonal paths) and I added a 10px cushion all around the sub-menus. Is that good enough now? :) It's not bad :-). Nit pick: you may want to use some a:focus magic to highlight the links in the toplevel menu for keyboard users. Oh, and it works nicely with Camino 1.0, 1.1a1 and Camino trunk builds (hardly surprising, same rendering engine as Fx 1.5, Fx 2.0RC and Gecko 1.9 trunk respectively). Camino 0.8.2 is _really_ old. Nit pick: in your browser support list, under Mac, you mention 'Firefox 2.5.0'. There is no beast like that. Firefox 1.5.x or Firefox 2.0 rc ? Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Relative positioning and Netscape 6
On Oct 16, 2006, at 10:35 AM, Andrew Ivin wrote:
I am trying to find out what Netscape 6's capabilities are as far as
relative positioning goes.
I have a page where I have a parent div, absolutly positioned, with
two relatively positioned child block level elemnets; one positioned
to the top left, the other top right.
The top right absolutely positioned element is ignoring the relative
container in NS 6, and is positioning relative to the viewport - top
right of browser window.
As always, a URL is more than useful...
And I'm not clear. Is the parent container {position:absolute} or
{position:relative;} ?
That makes a big difference.
If the parent container happens to be styled with {position:relative}
*and* is floated (left/right, doesn't matter), then Netscape 6
ignores it for the purpose of absolute positioning (top + right).
That is a bug.
Workaround: inside the floaed div, wrap the contents in a div, and
give that div relative positioning.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Firefox print style sheet bug
On Oct 13, 2006, at 8:14 AM, Pierre-Henri Lavigne wrote: I got the same problem in css as the following example page : http://www.getphuture.com/i/google.jpg The qualified persons on the mozilla IRC were busy at the moment I asked support. If someone has an idea about fixing it... I'll forward you answers if I find out more about it. And what is the problem ? The problems with the text, as seen in that screenshot (bold text that overlaps previous text/loose the white-space before the text- node) ? If yes, that is an OS X 10.4 only bug with some fonts: <https://bugzilla.mozilla.org/show_bug.cgi?id=288047>. If something else, please give some more details, a link to an example page, etc. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE shrinks/pushes margins on :hover
On Oct 11, 2006, at 6:47 PM, [EMAIL PROTECTED] wrote: I don't know where to look. Is this the infamous "hop on :hover" or "shrinking margins" or maybe "collapsing margins", mentioned on http://www.satzansatz.de/cssd/onhavinglayout.html ? Something completely different? As I said, I'm pretty sure the problematic elements do not trigger Layout in IE, but the symptoms sounds like those described at satzansatz.de... It could be one of those. A link would useful. My crystal ball is at the repair shop. Other possibility: <http://www.positioniseverything.net/explorer/guillotine.html> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari and bg-images for list bullets
On Oct 10, 2006, at 6:59 PM, John Faulds wrote: http://www.tyssendesign.com.au/examples/test.html The first is the misalignment of the bg-images that I'm using for bullets. Every other browser including IE5 displays them how I want them except for Safari. I did a quick search but the only thing I came up with was that this was a bug that only affected earlier versions but it seems to be the same in Safari 2.0 too. So, is there a solution? Does it require using a Safari-only filter? It is a known bug with Safari: happens when the background image is too large for the container. part of that bug has been fixed in nightly builds, but the 'hover' problems still is buggy in the latest Webkit build I have. A bug report has been filed ages ago (2years at least in my case), but the engineers there are not overtly concerned, it seems. Workarounds include: let the image move horizontally instead of vertically or vice-versa, use an oversized image with loads of white space, use different image for the various states... Here is a page of mines that tested this (created in June 2004, according to my notes). http://dev.l-c-n.com/Safari/background-hover.php Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE 7 but mainly (unsual) Safari probelm
On Sep 23, 2006, at 8:25 PM, Tee Peng wrote: I encounter a very strange Safari problem with floated divs. Running out of idea to fix it and thereby requested permission from client to post the page for help. In the below 'edit-waypoint' page, on the left column at the bottom, there are three floated divs with extra div wrapper. The "notes" textarea section should stay on the right and it display exactly where it should be in all browser except Safari. In Safari, instead of staying to the right, it fall below the floated divs on the left. Safari problem http://project.lotusseedsdesign.com/edit-waypoint.html width-less floats. Both #trip_edit and #trip_edit_rht are floated but you don't specify a width for the first one. Not sure why Safari is not collapsing the width of #trip_edit to the width of its content. Maybe because div.trip_info isn't set to clear the previous float. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari filter
On Sep 14, 2006, at 10:32 AM, Kenny Graham wrote: If it's for your own site then you might as well just do what works for you, but if it's a commercial site, or something you're doing for a client, I'm afraid you're in for a world of pain :-( Luckilly it's a semi-personal site. It's an interface for a database used by me and a large group of friends. That's why I'm able to serve as XHTML. I can just say "if you want access, don't use IE". So Safari support isn't a complete necessity, but since it's generally a good browser, I'd rather not discourage its use among my non-nerd friends. But you mentioning that most mobile devices are buggy with styles makes me strongly consider solving all this by simply not using a handheld stylesheet. Because of the type of site it is, styling isn't at all necessary. Each page pretty much consists of: h1, h2, ul, h2, ul, h2, ul. IE may have many more bugs than Safari, but at least there they can be worked around with something as simple as a child selector or a conditional comment. Well, it is a annoying bug in Safari. It simply ignores all media attributes and the 'alternate="yes"' attribute - and maybe more, but I didn't test further than those. Here is my test file: <http://dev.l-c-n.com/XHTML/test1-multistyle.xhtml> You might consider filing a bug report <http://bugzilla.opendarwin.org/> (I didn't find any open bug on the subject) Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Opera Mac Submit Buttons and margin/padding:0
On Sep 12, 2006, at 9:57 AM, Joe D'Andrea wrote:
If I use CSS of * {margin: 0; padding: 0} with the intent to set
margin and padding as-needed, things look pretty good where submit
buttons (input elements) are concerned, except for Opera on OS X:
http://test.joesapt.net/margin-padding/
The problem is that Opera uses some padding (5px, iirc) to define the
width of the pill shaped box.
I would rate that as a bug (or a weakness ?) in Opera's
implementation of Cocoa Widgets
Camino has similar problems when using the border property.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] XHTML Marquee
On Sep 8, 2006, at 12:28 PM, Richard Czeiger wrote:
I've updated the script and taken in to account the contrast factor
as well as the accessibility issue.
If I were to take it to the exterme, I'd dynamically generate the
control links.
As it is, i've chucked them into a separate
http://www.grafx.com.au/wip/marquee.html
Your scripts still fails to account for Gecko browsers that are not
Firefox: Mozilla Suite, Camino, ... [1]
as I mentioned yesterday.
The bad detection is in this line:
// Firefox
if (navigator.userAgent.indexOf("Firefox")!=-1 ||
navigator.userAgent.indexOf("Safari")!=-1)
Change Firefox to Gecko.
[1] <http://www.geckoisgecko.org/>
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] XHTML Marquee
On Sep 7, 2006, at 7:10 PM, Richard Czeiger wrote: I'd appreciate any comments/suggestions/criticisms... http://www.grafx.com.au/wip/marquee.html It look like this in my browser <http://emps.l-c-n.com/bm/marquee.png> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/ 20060907 Camino/1.2+ with minimum font-size set to 12px. Barely readable for my old eyes, even as it is static. See this for why. <http://www.geckoisgecko.org/> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Trouble with float layout (IE6 versus Firefox)
On Sep 7, 2006, at 5:27 AM, Doug Wigginton wrote: Thanks for taking a look. Just to confirm, on the right half of the screen the second Green div drops below the first green div when you resize to 600x800 in Firefox? Like this: [grey div][green div 1] [green div 2] and not [grey div] [green div 1 ][green div2] in your testcase, Firefox, Safari, Opera and other modern browsers drop the whole box containing [green div 1] and [green div 2]. That is the correct behaviour in this case: the width of the floated parent is not specified, and depends on the width of the content (known: the width+padding+border+margin of the 2 floated green divs; the width for those divs is specified). Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] XHTML X-Browser Standard for MP3
On Sep 5, 2006, at 2:01 PM, Sarah Peeke (XERT) wrote: <http://www.freefalljazz.com/> which has a sampler mp3 embedded on the homepage (bottom left). Apparently it's not working in FF WIN or IE6 WIN. It is not working for me on Camino (or other browser) Mac. I just see the words 'life is a Circle - Sampler'. But I don't have any RealPlayer installed. Why not add a link to the .mp3 file directly ? That would open in any app that can play mp3 files on the user's system. (works for me, anyway) Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE7 RC1 oddity
On Aug 30, 2006, at 5:46 PM, Tony Crockford wrote: here's the test page: http://www.boldfishclient.co.uk/test/widthtest.htm Test of widths IE7 in IE7 the first div is only as wide as its content and it seems to be because it's inside an undimensioned floated div... which is the correct behaviour? should an undimensioned div stretch to the full width of its container or only to the width of its content? There is no reason for the child divs to shrink wrap to the width of their content, unless they are floated or absolute positioned). They should be the same width as the parent (floated) div (as in Gecko, Safari, and other modern rendering agents). The floated div will be at least 800px wide (static div inside it that has width set) and maximum 900px wide (parent). It you add (absolute) positioning into the mix, then things become completed, and in that case I surely won't let browsers decide. Note, I notice that the first width-less div has both height and min- height applied. 2 'haslayout' triggers... That might complicate things in poor IE. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] i want my svg
On Aug 9, 2006, at 6:12 PM, Matthew Cruickshank wrote: Here's some versions with SVG's width/height removed... http://holloway.co.nz/wellypug/svg/svg-test1a.html http://holloway.co.nz/wellypug/svg/svg-test1b.html In test1a the SVG now scales based on CSS constraints which are a fixed pixel size. In test1b the CSS constraints are percentage based rules, and as you resize the browser window you'll see that preserving the aspect ratio means that the text will only line-up some of the time. http://holloway.co.nz/wellypug/svg/svg-test2.html This one resizes a second SVG without an aspect ratio, and keeps the text pretty-much where it should be regardless of the browser window. I don't have Opera/Safari to test on unfortunately, so I don't know if this will work on them. Safari doesn't support .svg. Yet. The nightly Webkit builds and Omniweb 5.5beta (Webjit based) do support it, and display your 3 test files the same way as Camino (Gecko trunk build) and BonEcho (Firefox 2.0 beta) do. Opera 9.01 Mac is identical in display as the others. No Firefox 1.5 on this PowerBook. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Custom Bullets
On Aug 9, 2006, at 11:50 AM, Paul Novitski wrote:
PS: Frankly, since the list-style properties apply only to
elements with {display: list-item}, I'm a little surprised that
it's correctly applicable to UL at all and not just LI, but I guess
it's just a quirk of CSS that we can give a LIST CONTAINER a LIST-
ITEM display. When it is applied to UL, I assume that its child
LIs inherit the property, but I don't see the inherent advantage to
a rule like ul {list-style...} over li {list-style...}. Myself, I
always roll my own lists just with li {list-style-type: none;}.
li {list-style-type: none;} applies to all li on a page, in a or
a
Personally, I do ul li {list-style: whatever}. or ul.classname li {}
CSS 2.1 Specification
12 Generated content, automatic numbering, and lists
12.5 Lists
http://www.w3.org/TR/CSS21/generate.html#q10
the keyword here is:
inherited: yes
The list-marker will be applied to the descendants of the , not
the itself, as that on has display:block, unless otherwise
specified.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Safari Rendering on Windows
On Aug 8, 2006, at 10:56 AM, Samuel Richardson wrote: http://www.getwebkit.org/ * Can someone who managed to install this tell us the following: is there any indication about the revision number of Webkit that browser is based on ? (in the about box if that exist, or the UA string - post it please ?) (I won't bother installing it, I have access to the real Safari and the WebKit nightly builds for OS X) * This browser is almost certainly not a perfect testing ground to see how the release builds of Safari (1.3/2.04) are doing. The WebKit code is much more recent than what Apple uses for the release builds: some bugs are fixed, there are new bugs, etc. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Safari Rendering on Windows
On Aug 8, 2006, at 10:56 AM, Samuel Richardson wrote: Apple has just released GetWebKit, it allows windows users to see how Safari will render web pages without then need to install OSX. http://www.getwebkit.org/ I don't think that is an 'Apple' release. They would have announced it by know. More probably, some people have taken the code and made it working on Windows. PS - I don't doubt that Apple, or the open-source community around WebKit, is working on porting WebKit to Windows. Checkins [1] in the past few months point that way (Cairo graphics Libraries, etc.). And also improve the synergy with KDE [2]. [1] <http://cia.navi.cx/stats/project/WebKit> [2] <http://webkit.opendarwin.org/blog/?p=62> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Floated OL Not Displaying Numbers
On Aug 8, 2006, at 10:37 AM, Nello Lucchesi wrote: I am trying to style an ordered list to display horizontally. I want the display to include the numbers (markers). At first, I tried display: inline; but that eliminated the markers since the items were no longer display: list-item. So, I tried a float instead. It works in Firefox but not IE(6). Please see: http://lucchesi.org/list.htm Can anyone explain to me why the item markers aren't displayed in IE? Unfortunately, IE's support for display:list-item is weak, to say the least. Because the list-items are floated, they become display:block in IE (wrong). Additionally the acquire 'layout' [1] which also messes up with list-markers. You list-markers are also missing in Opera (still) (tested 9.01, Mac OS X); that is a bug in Opera imho. Solutions ? Not many... add the numbers manually? or use the DOM to append them with a script. [1] <http://www.satzansatz.de/cssd/onhavinglayout.html#list> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Support for IE5/Mac? (was Browser stats)
On Aug 3, 2006, at 12:23 PM, SunUp wrote:
I know how to prevent v.4 browsers from getting my styles, but how do
I stop IE5/Mac from getting them?? All I know how to do is to give
them something different, not how to exclude them entirely.
wrap your entire stylesheet in a @media statement, like so:
@media screen {
/* all my ruleblocks */
}
then a the very top of your stylesheet, add a link to a IEMac
stylesheet, hidden from other browsers:
/*\*//*/
@import "/path-to/ieM.css";
/* ie mac */
That said, I never had big problems in supporting IE Mac. A few extra
rules needed, but much less than what iExploder windows needs.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Table Attributes and CSS
On Aug 3, 2006, at 10:20 AM, Rachel May wrote: Cellspacing from memory you can't control through css although I could be wrong about that...? cellspacing is controlled through the border-collapse and border- spacing properties. [1] Presently iExploder only supports border-collapse:collapse, and doesn't know anything about border-spacing. Other browser have full support for those (although not always correct; cough cough, Safari and Konqueror). border-collapse:collapse is equal to the cellspacing attribute set to 0. PS - cellspacing and cellpadding are perfectly valid attributes for all DTD. [1] <http://www.w3.org/TR/CSS21/tables.html#borders> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Opera Bug? (Table-displayed, left-floated, min-width content)
On Aug 1, 2006, at 11:05 PM, Joe D'Andrea wrote:
An element with display:table shrink-wraps the width, just as a
real table would do.
And Opera is known to be more aggressive in this than some other
browsers.
Aye. But if each item/link has a minimum width, wouldn't that count
for something? Put another way, if I had a table row with min-width
cells, would it wrap to two rows?
It is a bit more complicated. When you use display:table; browsers do
this:
<http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes>
aka, add a few anonymous boxes around your group of elements, one of
them being a table-cell.
That table-cell wraps around all your floated blocks.
So that is different than a real table, which would contain a whole
series of table-cells.
If you put your series of links in a (one) real table-cell, and use
the same styling (float), odds are that you'd see similar behaviour/
differences between browsers.
The HTML and CSS 'table' model is a pretty complex thing, and all
browsers use different algos to compute width (and are reluctant to
change anything...).
And on the side, you won't need to clear those floated elements as
{display:table} establishes a new block formatting context and
contains the floated blocks any way.
True. That note was actually based on IE (which won't use display:
table but an entirely different approach, and still needed to clear
the float). I didn't need to mention it in the context of this
particular issue.
Unrelated to your test case, as IE doesn't do display:table anyway.
You'll probably need a 'haslayout' trigger for IE, which would
achieve the same: containing the floats (and that is a bug in IE,
anyway). [1]
[1] see my little exercises here:
<http://dev.l-c-n.com/IEW/simulations.php>
which is partly a spin off from this article:
<http://www.satzansatz.de/cssd/onhavinglayout.html>
PS - If you know the number of links, and their minimum-width, you
could give your a minimum width as well.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Opera Bug? (Table-displayed, left-floated, min-width content)
On Aug 1, 2006, at 8:40 PM, Joe D'Andrea wrote:
Minimal Test Case: http://test.joesapt.net/opera
Includes links to BrowserCam shots and a few more variations for
good measure.
Markup:
1 2 ... 8
Style:
p { display: table; }
p a { float: left; min-width: 16px; }
Whatever the rationale for using a , what is the idea behind using
{display:table} ??
... because I'm not sure this is strictly a bug. An element with
display:table shrink-wraps the width, just as a real table would do.
And Opera is known to be more aggressive in this than some other
browsers.
Add to that, your 'table' element only contains *width-less* floated
elements. That may complicate the computation of width.
And on the side, you won't need to clear those floated elements as
{display:table} establishes a new block formatting context and
contains the floated blocks any way.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Default browser stylesheet values
On Aug 1, 2006, at 5:22 PM, Nick Gleitzman wrote:
Hmm - OK, answers own question - FF on my Mac, with a little
digging (Firefox.app > Show Package Contents > Contents/MacOS/res/)
coughs up a file called html.css - which *appears* to contain the
defaults.
There's a bunch of others, too:
forms.css
mathml.css
platform-forms.css
quirk.css
ua.css
viewsource.css
Those are indeed the stylesheets that control how Gecko renders pages
by default. Except for platform-forms.css, which does not exist
anymore in Fx 1.5. Safari uses very similar rules, stylesheets can be
found in System -> Library -> Frameworks -> Webkit.framework and
drill down further.
Opera's defaults are hard coded in the binary and not accessible, but
look more or less like the sample html 4.0 stylesheet in the CSS 2.1
docs.
iE's stylesheets are hard coded as well, and not publicly available.
I often noticed, though, that left on its own (using defaults) that
browser can be rather helpless. It is better to specify everything
you need (margin/padding/line-height/...) to avoid problems.
Beside looking at the UA stylesheets, a good reference for the
defaults is the HTML 4.01 DTD. (e.g. p, hx, div have {display:block}
by default).
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] firefox doesn't render svg file
On Jul 30, 2006, at 6:50 PM, [EMAIL PROTECTED] wrote: i've been experimenting all night and firefox doesn't want to render the svg file at all. i get a download dialog box about the svg file. i just now found out there is not a svg plugin in the download actions dialog of my copy and it is the latest update. could someone point me in the direction to get the svg plugin that is supposed to be native to firefox. i'm really disappointed. http://www.alforddesigngroup.com/sandbox/svg-test-1.html maybe someone has a copy of firefox that will render the svg file on this page natively. I've no idea what is wrong (and you file works as I expected - I think- in Opera). I saved your file (+svg) to my local dev server, and there it works correctly, although the svg file doesn't scale to the size of the . PS - firefox 1.5+ does not need any plugin to display svg file. Support is build-in. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Safari CSS bug?
On Jul 30, 2006, at 3:16 PM, Jason Witherspoon wrote: http://www.holymountain.com/xhtml/discog.htm ...and I've set a few non-standard font options for headers: font-family: Harrington, Papyrus, Herculanum, "Trebuchet MS", Trebuchet, Verdana, Geneva, Arial, sans-serif; These turn up fine on IE & Firefox (SeaMonkey, actually), but on Safari, the headers simply display as the body font. However, the same font-family directive used on an (as per the menubar) displays the correct font. Because Safari, unlike other browsers doesn't create artificial (syntetic) bold faces when the font-family doesn't contain bold glyphs (on my machine, Papyrus appears to be used). It is not a bug. The CSS specs don't require a browser to create artificial bold faces. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] ID Attribute for Anchor Points
On Jul 28, 2006, at 3:40 AM, James W. wrote: I am proposing that we use: Heading It works on all browsers but Safari. Issue number #1 would be that name is not a valid attribute for h2. Issue number #2: Safari indeed does indeed have problems with anchors. - if the user is on page xx.html and clicks on a link that points to an anchor on that page, it works OK in Safari. - if the user is on page yy.html and clicks on a link that points to an anchor on another page (e.g. xx.html#myanchor), that FAILS in Safari. Issue number #3: Safari doesn't move the focus to the anchor (problem of keyboard accessibility). The page will correctly come into view, but the focus is still on the point of origin (similar problems as with iExploder, as pointed in the article mentioned by Thierry). Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Form check
On Jul 18, 2006, at 3:45 AM, Jeff Van Campen wrote: By the way, this brings up an interesting issue. Does anyone know of if Mozilla provides a guide to which Firefox versions are based on which Mozilla builds? Is the relationship even that clear any more? Check out the user agent string. (Open the about box and you'll see it) ex: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: 1.9a1) Gecko/20060713 Minefield/3.0a1 The key is v:1.9a1 which points to Gecko 1.9, the current trunk builds Fx 1.0.x is based on Gecko 1.7 Fx 1.5.0.x is based on Gecko 1.8 Fx 2.0 will be based on Gecko 1.8.1 Fx 3.0 will be based on Gecko 1.9 Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] image menu failing in safari
On Jul 11, 2006, at 2:11 AM, Warren Cardinal wrote: I have been told that this menu is all messed up in Safari... http://www.dbuchter.com/transfer/peapod/new/ anyone know why? looks fine in FF and IE on PC. I'm stumped Step one: validate your mark-up. Step one one: validate your mark-up. Step two: may set a width on those floated ? Currently, each li collapses in width to the width of the text node inside it. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] html validation: exactly what is it good for?
On Jul 9, 2006, at 7:53 PM, Christian Montoya wrote: Time and time again: - If you serve an HTML doctype as text/html (and you really should use HTML Strict to avoid getting quirks mode in browsers like IE), then validation isn't necessary, because you are relying on the SGML parser with all of it's wonderful error correction to fix your mistakes when the page is rendered. Even so, if you wonder why your CSS is not working or your DOM scripting fails, then validating the HTML is a good place to start. Hear, hear. As we all know, html parser 1 will understand and interpret your error in one way, while html parser 2 will have another understanding, and html parser 3 yet another interpretation. It is pretty easy to install the W3C validator on your own development machine. <http://validator.w3.org/docs/install.html> For OS X there is even a standalone package that only requires a double-click on a disk-image. <http://habilis.net/validatelet/> For OS X see those instructions on Apple's site: <http://developer.apple.com/internet/opensource/validator.html> There is a similar how-to article for Ubuntu Linux; I lost the URL unfortunately. Your favourite search engine knows about it, I guess. - If you serve an XHTML doctype as text/html, well, don't. :-) +1 - If you serve an XHTML doctype as application/xhtml+xml, then your question would be, "why doesn't my page display at all?" And the answer would be, validate. Welformed XML is not necessarily valid XHTML, but that is another discussion. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Opera 8 and 9 difference
On Jul 8, 2006, at 7:12 AM, CK wrote:
Hi,
This appears some nested CSS rule, which I'm unfamiliar. Would you
elaborate, off-list if preferred, with an explanation of use and
function?
I used the following code to fix this in Opera 8
/* Opera */
@media all and (min-width: 0px) {
div#meny ul {
bottom: -5px;
}
}
CSS3 mediaqueries.
<http://www.w3.org/TR/css3-mediaqueries/>
Only supported by Opera, so far. Gecko and Webkit (Safari) are not
far away from supporting it too.
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
[off list] Re: [WSG] Opera 9 and standards support
David Storey wrote: I hope you all like Opera 9. As always if you have issues in Opera on your site feel free to contact me and we will help you find the cause of the problem. If there is anything that Opera doesn't support that you come across when writing scripts then I'll also see what I can do. With Opera 9 we've added DOM Level 2 Style, contentEditable and DesignMode which I think will be useful additions for many designers and support for Web forms 2.0 which is a peek into the future of what we are trying to achieve with the WHAT WG along with Mozilla and Apple. Hi David, Taking you at your word... Some long-time issues: ::first-line, and -- essentially, because Op threats :first-line as a block-level element filed as [EMAIL PROTECTED], test case at (mentioned in the bug report): <http://dev.l-c-n.com/_opera9/first-line-O9.php> Also, as seen the testcase, and mentioned in the bug report, ::first- line 'leaks'. ul li::firs-line should only be applied to the li, child of ul. However, due to the existence of the selector, Op starts to threat all instances of first-line as a block. (OK, that one is better than in Op 8) Makes the use of ::first-line virtually impossible. filed as [EMAIL PROTECTED] overflow (hidden/auto) adjacent to right floated block drops below/ clears the floated block http://dev.l-c-n.com/_opera9/floatRight-overflow.php All those bugs are long-time issues, going back to Op 7.5 at least. Is there a way to keep track of bugs filed ? Opera is the only place where I've filed bugs and never get any feedback. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
[off list] Re: [WSG] Opera 9 and standards support
David Storey wrote: I hope you all like Opera 9. As always if you have issues in Opera on your site feel free to contact me and we will help you find the cause of the problem. If there is anything that Opera doesn't support that you come across when writing scripts then I'll also see what I can do. With Opera 9 we've added DOM Level 2 Style, contentEditable and DesignMode which I think will be useful additions for many designers and support for Web forms 2.0 which is a peek into the future of what we are trying to achieve with the WHAT WG along with Mozilla and Apple. Hi David, Taking you at your word... Some long-time issues: ::first-line, and -- essentially, because Op threats :first-line as a block-level element filed as [EMAIL PROTECTED], test case at (mentioned in the bug report): <http://dev.l-c-n.com/_opera9/first-line-O9.php> Also, as seen the testcase, and mentioned in the bug report, ::first- line 'leaks'. ul li::firs-line should only be applied to the li, child of ul. However, due to the existence of the selector, Op starts to threat all instances of first-line as a block. (OK, that one is better than in Op 8) Makes the use of ::first-line virtually impossible. filed as [EMAIL PROTECTED] overflow (hidden/auto) adjacent to right floated block drops below/ clears the floated block http://dev.l-c-n.com/_opera9/floatRight-overflow.php All those bugs are long-time issues, going back to Op 7.5 at least. Is there a way to keep track of bugs filed ? Opera is the only place where I've filed bugs and never get any feedback. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Spans & Padding
On Jun 5, 2006, at 8:37 PM, Ryan Moore wrote: I am having a real problem with the this mark up. [snip code] The problem is in the the .featured_left_col & featured_right_col both choose to ignore anything related to width, padding or margins? Ideally, I'd like to be able to place a border around the featured_listing class but I can't do that if I replace the featured_col. with div's. The border get's eaten up and will not display. This occurs in all major browsers on PC. Width/height does *not* apply to inline elements. <http://www.w3.org/TR/CSS21/visudet.html#propdef-width> You have mark-up errors: what is that period doing there? white-space before the class name class names will never be applied that way. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Font property
On Jun 6, 2006, at 4:02 PM, Herrod, Lisa wrote:
From what I understand, to use 'font' as a shorthand property you
have to
include the size and font-name as a minimum (in that order).
I thought the order of properties was important?
for example, isn't weight listed first?
i.e
{font: weight style variant size/line-height font-name}
or do you guys find it works in any order?
Yes order is important in this case. But only 2 properties are
required: font-size and font-family.
Note that adding additional properties can lead to surprising results
sometimes
h1 { normal 1em/2 sans-serif}
the 'normal' will apply to all 3 properties: weight, style, variant
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Spans & Padding
On Jun 5, 2006, at 8:37 PM, Ryan Moore wrote: I am having a real problem with the this mark up. [snip code] The problem is in the the .featured_left_col & featured_right_col both choose to ignore anything related to width, padding or margins? Ideally, I'd like to be able to place a border around the featured_listing class but I can't do that if I replace the featured_col. with div's. The border get's eaten up and will not display. This occurs in all major browsers on PC. Width/height does *not* apply to inline elements. <http://www.w3.org/TR/CSS21/visudet.html#propdef-width> You have mark-up errors: what is that period doing there? white-space before the class name class names will never be applied that way. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Mac and CSS
On May 21, 2006, at 1:34 PM, Veine Vikberg wrote: Thanks for testing - and you are right - IE5 Mac - it seems like I have a problem with the absolute positioning of my navigation - it displays it exactly as intended, but 380px lower and 100 from the left on all pages - anyone know if this is a Mac bug, or if there is a workaround for it? Definitively not a *Mac* bug :-). But possibly one in IE Mac. That #nav is absolute positioned within a table-cell. Maybe the browser doesn't like that too much. deleting all that a.p. stuff, and #nav positions itself correctly, in IE Mac and other browsers like Camino, Safari, iCab, Firefox, Opera on my PowerBook. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] onKeyPress or not onKeyPress
On May 10, 2006, at 12:09 AM, Al Sparber wrote: Test this page for yourself: http://www.projectseven.com/testing/keypress/ Safari 1.0x (v85.x.x) fails this: there is simply no way to access links with the keyboard. This has been corrected (by way of a user pref) in Safari 1.1 (not available to OS X 10.2 Jaguar, if memory serves). iCab 3.0 does not offer keyboard access to links (via tab key). onclick event: fails in IE Mac Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Strict on Internet Explorer 5/Mac
On May 9, 2006, at 3:05 AM, 1802 wrote:
I'm preparing a new version of my site, and I've decided to go on
strict (yes, it's time).
Beta is "under costruction", but it seems to run well on Firefox,
Safari, Opera and Internet Explorer 6/PC. The problem is Internet
Explorer 5/Mac: I can't see nothing with this apps.
Here the link
http://homepage.mac.com/matteo.discardi/beta/home.html
(lot of page are OK, but I have to ceck syntax; css are ready on
70-80%)
Hi Mateo,
Your site loads fine on my side in IE Mac 5.23.
The one problem I see is the menu. You use the float property on the
#menu li, but you don't specify a width.
IE 5 Mac is a CSS 2.0 browser, and CSS 2.0 *requires* a width for
floats [1].
You can work around this:
* html>body #menu li {width: 1px; white-space:nowrap}
* html>body #menu li a {display:inline-block}
[1] <http://www.l-c-n.com/IE5tests/float2misc/#flwidth>
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Styling tbody?
On Apr 28, 2006, at 1:17 PM, Kevin Futter wrote:
a de facto heading. I'd hoped to be able to group them via the
element, but find myself completely unable to style them. I'm
trying to
apply a border to the sections, but it only works if
border-collapse is set to collapse, otherwise I get nothing (but
the table
then ignores the padding applied to its parent element). If I
apply a
border style to the individual s, it negates the border
altogether.
Let's just say that I'm confused and frustrated :-)
Hi Kevin,
The problem is because doesn't have a border attribute.
For more info
on this (or any other tags):
http://www.w3schools.com/tags/tag_tbody.asp
But I'm not using an HTML attribute (), I'm using
CSS
(tbody { border: 1px solid #CCC; }), and as far as I was aware, all
block-level elements were suitable targets for CSS borders. Are you
suggesting that if an element doesn't have an HTML border
attribute, it
can't be styled with the equivalent CSS?
tbody can perfectly well take a (css) border, as long as the table is
set to border-collapse:collapse.
And it does not work in iExploder.
td/th/tr is painted on top of tbody (rowgroup), assuming a same
width border on both elements, then the border on tbody won't be
visible. [1]
A little painting exercise: <http://dev.l-c-n.com/tables-4/table-
border.php>
[1] <http://www.w3.org/TR/CSS21/tables.html#table-layers>
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Letterspacing body content
On Apr 9, 2006, at 9:32 AM, Christian Montoya wrote: Besides, I thought the body text of http://christianmontoya.com looks better with a 1px letter-spacing. Anyone with the web developer's extension can compare it to the default look. So is it better with or without the letter spacing? I'm going for as much readability as possible without having to change the color scheme. Thanks in advance. It is a bad idea to use letter-spacing for body text, imho. You page looks much better at the defaults <http://www.l-c-n.com/b/chris2.png> with letter-spacing <http://www.l-c-n.com/b/chris1.png> without. OS X, Camino and Firefox. And no, I don't have Verdana activated. Besides, as others already mentioned, it would be better to use ems for this. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Definition List for Products/Items with Image
On Apr 4, 2006, at 2:58 PM, Daniel Nitsche wrote:
I had a quick go, and this is what I came up with (assuming a
100x100px
image):
Product title
Product description - this can be as long as you like
dl { position: relative; }
dl dt { margin-left: 110px; font-weight: bold; }
dl dd { margin-left: 110px; }
</pre><tt>dl dd img { position: absolute; top: 0; left: 0; width: 100px;
</tt><tt>height:
</tt><pre style="margin: 0em;">
100px; }
As others have said, I like this better than putting the image in
the dt.
This works in Firefox (Linux and Windows) and Konqueror, but breaks
in IE 6
(it seems to be ignoring the absolute positioning of the image).
Perhaps
someone could expand on this to make it work in IE?
As a rule of thumb, whenever you use position:relative in IE win, you
should give the element 'layout' [1].
* html dl { position: relative; zoom:1 /* or other layout triggers */}
[1] <http://www.satzansatz.de/cssd/onhavinglayout.html>
Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Safari and table row id
On Mar 28, 2006, at 2:06 PM, Daniel Nitsche wrote: I'd try replacing the element that the anchor is on if possible, maybe attach it to either the td or the ip address itself (if it is in a p tag or whatever) Also try removing the _ in the anchor names, this may cause it to choke. Samuel Kevin Futter wrote: Not sure how on-topic this is, but I'll give it a shot. I've developed an internal page (sorry, no link to give you) that pulls IP addresses out of a database and allows you to 'manage' them (edit, change, add notes etc). Once edited (on a separate edit page), I send the user back to the main page, which is meant to jump down to the table row they've just finished editing. Works OK everywhere I need it to except Safari, which seems to have an issue scrolling to an anchor within a table - it just stops at the top of the table. I'm using URLs like this: (...)/index.php#ip_40 to achieve this, where #ip_40 is the ID of the tr element in question. I've Googled everywhere but can't work out whether this is correct behaviour (ie, anchor functionality not valid for tr element) or a bug in Safari. It definitively is a bug in Safari's handling of URL fragments. www.example.com/page.html#anchor fails when coming from another page but jumping inside a page: does works. Doesn't matter what elements are used. Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
