Re: [WSG] [OT] Google search/index/webmaster help
On Nov 2, 2009, at 6:58 AM, Adam Smith wrote: Swami; I'll hazard a guess here and assume you're using Firefox; and you've done what I did and gone tohttp://maps.unimelb.edu.au/sitemap.xml , seen a mass of test on screen Because that file is being served as 'text/html' instead of 'text/xml' as it should. That is server misconfiguration. I'm not surprised Googlebot doesn't pick it up. Safari shows the same issue. Philippe --- Philippe Wittenbergh http://l-c-n.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] how to set table column widths with CSS
On Jan 11, 2008, at 11:51 PM, Alastair Campbell wrote:
On Jan 11, 2008 7:29 AM, Philippe Wittenbergh [EMAIL PROTECTED] wrote:
col:first-child {width:10em;}
col:first-child+col {width: 5em;}
From memory, I don't think col has children as such, it's quite a
headache:
https://bugzilla.mozilla.org/show_bug.cgi?id=915
I'm styling the col element, not a descendant or child of col
(there are none, anyway).
(col:first-child applies to the first column, child of colgroup)
width applies perfectly to the col element.
http://www.w3.org/TR/CSS21/tables.html#columns
To anyone who mentioned that IE (6) doesn't support these selectors,
I **know**.
And that was also the point of my post. The OP wanted a solution
without the use of classes (or a minimal use of them).
She could attach class to each col element, eventually.
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] how to set table column widths with CSS
On Jan 11, 2008, at 2:59 PM, Katrina wrote:
Gday,
Can someone please remind me how to set the width on a simple table
column without suffering classitis?
Doctype: HTML4.01 strict. Must validate.
What is wrong with classes ?
else:
col:first-child {width:10em;}
col:first-child+col {width: 5em;}
...
or
td:first-child {width:10em;}
td:first-child+td {width: 5em;}
...
But: congratulations! your stylesheet just took a beating as far as
performance goes.
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] Float-less layouts
On Jan 8, 2008, at 1:48 AM, Thierry Koblentz wrote: I'd appreciate any comment that would help me improve this article: http://tjkdesign.com/articles/float-less_css_layouts.asp Demo: http://tjkdesign.com/articles/css-layout/ no_div_no_float_no_clear_no_hack_no _joke.asp Nice write-up. One of the issues with this technique: you can't use the 'columns' as a containing block for absolute positioned elements. Another issue: width on a 'table-cell' is more like 'min-width' than 'width'. The cell can expand in width if it contains e.g. long unbreakable text strings (or strings of text with white-space:pre). This can eventually be controlled by wrapping such content in a 'overflow:auto' wrapper, but not always. 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] Site Check
On Dec 21, 2007, at 7:30 AM, CK wrote: http://working.bushidodeep.com/kevon/index.html The footer (#header) that covers the scrollbar is quite disturbing. 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] Browser test: Construct
On Dec 9, 2007, at 4:37 PM, Christian Montoya wrote: Is there any way at all to prevent the FAYT behavior? If I apply return false, will that work? I don't know :-) Nobody ever managed to block FAYT, seen from here. To set FAYT to work automatically, add user_pref(accessibility.typeaheadfind.autostart, true); in your user.js (or use about:config). 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] Browser test: Construct
On Dec 10, 2007, at 3:36 AM, Christian Montoya wrote: To set FAYT to work automatically, add user_pref(accessibility.typeaheadfind.autostart, true); in your user.js (or use about:config). OK, I added return false; to the keybindings and successfully repressed FAYT in FF on WinVista, but I don't know if that works in all gecko browsers. Gecko is Gecko :-) I checked your page with Fx 2 and the nightly builds of both Camino and Minefield: Fayt is not triggered. Camino 1.5 appears not to 'get' it here, Fayt is triggered anyway. I'll check if there is a known issue/limitation around that. But if I were you, I wouldn't worry about it. There are a few known bugs with keybindings in current nightlies on Mac, but those should be fixed by the time Gecko 1.9 is released. None affected your test page. 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] Browser test: Construct
On Dec 9, 2007, at 11:49 AM, Christian Montoya wrote: I just created a layout tool: http://lab.christianmontoya.com/ construct/ [...] If I could get some tests on older browsers and other operating systems, that would be great. Thanks in advance! Gecko nightly builds (Camino Minefield) seem to do what you expect. Of course, using 'J', 'K', 'L' triggers FAYT (Find as you type) when set to start automatically. Most people reasonably versed in the use of Gecko browsers have it set that way. Safari 3 doesn't get your keyboard input. OS X 10.4.11. 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] padding on the bottom ;-)
On Dec 7, 2007, at 4:31 PM, Taco Fleur wrote:
Having the same issue with another layout, but in FireFox
http://www.clickfind.com.au/ the 3 panels at the bottom of the page.
The issue is also visible in Safari and Opera 9.5b, if what you mean
a a kind of vertical lines under those 3 boxes.
That comes from the margin on the p that is collapsing through the
divs
(div#box-1-c p, div#box-2-c p, div#box-3-c p {... margin-bottom:
0.5em;})
Set the margin to 0 and that issue disappears.
That is the correct behaviour, btw.
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] Font-size-adjust (was: RE: Disabling Fonts in Font Stacks)
On Dec 3, 2007, at 6:05 AM, Terrence Wood wrote:
If, in laymans terms, font-size-adjust allows you to specify the
font-size based on the x-height of a preferred font-family, how is a
rendering engine supposed to deal with this if said font is missing?
Font-size-adjust works based on the first font specified in the list
for font-family, doesn't matter if the font exists on the system or not.
example.
p {font-family: 'Lucida Grande', Arial, sans-serif; font-size-adjust:
0.54;}
On Win OS, Lucida Grande is not present (OS X only font), the size of
the text will nevertheless be adjusted (slightly enlarged) as Arial
has an aspect ratio of 0.52. This is interesting in the case of a
stylesheet that specifies 'Verdana, Arial, sans-serif', and where the
page author bases all his work on the size of Verdana (we all know
that this is big font, with rather large aspect ratio). Verdana at
12px maybe or not be readable to the user, Arial at 12px looks and
feels much smaller, and will probably be harder to read for the user.
And how does it resolve line-height issues for fonts that have a low
aspect ratio?
Could you clarify ?
Line-height depends on the used value for font-family, basically.
Personally, I would like to see some decent column support before
trying to exert this degree of control on font-sizing.
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] RE: Disabling Fonts in Font Stacks
On Nov 30, 2007, at 10:42 PM, Frank Palinkas wrote: How can we encourage the other (non-Mozilla) browser manufacturers to add support for this very useful feature? If I understand your question, please download, install, and have a look at Opera (release version 9.4). 9.24 ? or 9.5b ? The tool I think you're looking for can be found by going to: Tools/Preferences/Advanced/Fonts. This opens the extensive Desired font selection dialog box. Please have a look? Apple menu PreferencesAdvanced tab. Not everybody uses windoze. That is about user preferred settings (aka preferences). You can change those in any browser worth it weight in bytes. It won't necessarily override the fonts set in the user stylesheet. The question I answered to was about font-size-adjust, a css-3 property. BTW - On the (original) subject of testing the effect of various fonts, on OS X this is very easy: Open Fontbook.app and just disable/ enable the fonts you want. For some browsers, you'll need to restart before the changes take effect. 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] RE: Disabling Fonts in Font Stacks
On Nov 30, 2007, at 5:31 AM, Kroon.Kurtis wrote: I'm also late to the party, but I wanted to add something that no one else seems to have mentioned -- font-size-adjust (from CSS 2, but removed -- alas! -- from CSS 2.1 due to lack of support). It is part of CSS 3 http://www.w3.org/TR/css3-fonts/#font-size-props ... Now, the (rather substantial) disadvantage: As far as I can tell[3], font-size-adjust is only supported in recent Gecko browsers (e.g. Firefox 2). And for Firefox 2.0.0.x, only on Windows. But fear not, It is supported on all platforms in the upcoming Firefox 3.0. Cool. It is a very useful feature to produce decent quality text. Not only for the described case above, but also for example for the case where you have different fonts used within the same block of text (e.g. a paragraph with some code in). (decent quality text: because typography on the web is still a far cry from what it should be). Which leads me to my last question (on this topic, anyway): How can we encourage the other (non-Mozilla) browser manufacturers to add support for this very useful feature? 1. By using it ? 2. File bugs against your favourite Rendering Engine (I don't need to, It is already supported in my browser...:-)) for WebKit, it is bug 15257 http://bugs.webkit.org/show_bug.cgi?id=15257 To my surprise, nobody had requested that when I filed that bug. 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] RE: Disabling Fonts in Font Stacks
I wrote: Apple menu PreferencesAdvanced tab. Not everybody uses windoze. Darn stupid mistake Opera menu PreferencesAdvanced tab. 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] Input tag - closing tag optional?
On Nov 26, 2007, at 8:00 AM, Dusan Smolnikar wrote: I'm afraid browser don't agree with this, though. I'm not sure about input but I'm positive that div/div is not the same as div / as far as browser rendering goes. Actually as far as XML (and consequently XHTML) is concerned: input type=text name=a value=a/input Is the same as: input type=text name=a value=a / Depending on the mime type there is a huge difference. text/html -- sgml parser in use application/xhtml+xml -- xml parser is in use. And no, slamming an xhtml doctype at the top of the page has no effect (doesn't affect the mime-type). Note: the upcoming Firefox 3 and other browsers using the Gecko 1.9 rendering engine are more strict in handling this. 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 doesn't play nice with Opacity
On Nov 13, 2007, at 10:06 PM, James Ellis wrote: I still find it a bit odd that setting opacity on an outer box affects the opacity on the inner box. For instance when you have nested white boxes each with an opacity of 0.5 over a black background they both end up having 50% black backgrounds (~ #7f7f7f). Opacity is not a function of background-colour, it affects the whole box _and_ its descendants. That is, everything that is inside that box will see its opacity lowered. If they are positioned absolutely over each other the the opacity works as expected, the top most one having the expected background colour of #bfbfbf. That would be the case if none of the boxes are descendants of each other. If you are looking to have a semi-transparent background, you have to look for rgba or hsla colours. These colour values are only supported by WebKit/Safari 3.0beta + and Gecko 1.9a (what will be Firefox 3.0/Camino 2.0/SeaMonkey 2.0). I've been told that Konqueror 4.0 will also support this (QT4). You can of course use rgba or hsla colour for any property that takes a colorvalue as value: border, background, etc. Defined in the css3 color module http://www.w3.org/TR/css3-color/#rgba-color http://www.w3.org/TR/css3-color/#hsla-color 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 doesn't play nice with Opacity
On Nov 13, 2007, at 10:51 AM, Tee G. Peng wrote:
body {background:#FFB701}
where footer wrap has opacity of 0.92 with a bg color
#ftr_wrap {background:#0d0d0d;
opacity:0.92;}
and 3 columns has
#col1, #col2, #col3 {background:#1a1a1a;}
I think Safari and Firefox got it right, that the 3 columns'
elements are 'inheriting' the opacity from the #ftr_wrap, which is
what I wanted.
But Opera doen'st seemed to agree.
Safari and Gecko browsers are doing the right thing.
Opera 9.2 is trying something that looks like, but the resulting
colour differences between the background-colour of #ftr_wrap and the
background-colour of the 3 columns is really minimal. After going
over the whole thing with a colour sampler, I could 'see' the
difference :-) (that is : the OS X colour-picker saw it, not my eyes).
What Opera 9.5 beta is trying is puzzling. The whole footer has a
yellow background. No trace of any background-colour as specified in
the style-sheet, not on #ftr_wrap and not on #col1, #col2, #col3.
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] Request possible?
On Nov 6, 2007, at 7:48 PM, Gunlaug Sørtun wrote: http://www.gunlaug.no/tos/alien/mv/test_07_1106.html ... Otherwise: no problem. No problems ? With Fx Mac and Safari 2.04, 3.03beta and the latest WebKit builds, the is a slight overlap: the top part of the floated block is partly covered by the text outside of it. In Gecko the floated block is under that text, in WebKit, the floated block is on top. Depending on your font-size, this is more or less pronounced. (It is a known issue/bug with that kind of trick, btw; the floated block is placed slightly too high in the flow). 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] SilverLight
On Oct 30, 2007, at 3:21 PM, Michael MD wrote: The Silverlight build process produces a .dll. You need the Silverlight plug-in to render the resulting html page. Also, from a quick test, it will only render in IE and the Gecko range. Forget Opera, Safari for windows, etc. If they are really serious about getting people to use Silverlight they need to provide the plugin for a wide range of popular browers and operating systems.. (definately including Safari, Opera, Mac browsers, Linux browsers, etc ) ...until then I can't see why I should bother with it... (of did I miss something?) Well, the release version of the plugin actually works in Safari (and WebKit builds) and Gecko Mac (SeaMonkey, Camino, even Firefox). iCab and Opera (Mac, 9.23 and 9.5 beta) are not supported. In the beta process, they were doing some flipping browser detection **from within the plugin**, and only checked for Safari or Firefox, as opposed to check for Gecko. The demos I've seen still only work half and half on Mac browsers, except Firefox 2.0.0.x and Safari. 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] skip to content: care of accessibility causing usability
On Oct 28, 2007, at 11:44 AM, Tee G. Peng wrote:
... so I came out with this technique:
teesworks.com/ (move your mouse to the top to see the result).
Haven't show it to client yet. Been working on this site in the
last 2 days, I find that I am getting so annoyed by the surprise'
everytime the hover pops up. There is no way to miss it everytime I
move the cursor to the top.
I agree with you: the 'hover' technique is way more annoying, and it
will annoy way more people.
'skip links' should be visible all the time, as they are useful for
sighted users (e.g using the keyboard).
A compromise solution I have used: when a client doesn't want them,
hide them (position them of screen, not display:none), but make them
visible when those links are focussed (by pressing the tab key).
a.skiplinks {position:absolute; left: -999em;}
a.skiplinks:focus,
a.skiplinks:active {left: 1em;}
:active state is for iExploder. Add additional styling to taste.
Not really perfect, just a compromise.
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] browsers render differently with Optroup
On Oct 24, 2007, at 3:27 PM, Tee G. Peng wrote: I am working on a web form that has Optgroup in it, and the first time I realized browsers render this attribute differently. IE Mac displays 'CA' in your 1st example IE 7 Win displays 'CA' in your 1st example Opera 9.5 alpha: idem ditto. I made an example page with markup copied from the above page http://lotusfromthemud.com/option.html Under 17.6.1 it says (specifically for label in option): http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION label = text [CS] This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label. That sounds, to me, as validating what Safari, IE Mac, IE Win Camino are doing. Note that Firefox is not wrong by the description given 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] browsers render differently with Optroup
On Oct 24, 2007, at 10:37 PM, Tee G. Peng wrote: Under 17.6.1 it says (specifically for label in option): http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION label = text [CS] This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label. That sounds, to me, as validating what Safari, IE Mac, IE Win Camino are doing. Note that Firefox is not wrong by the description given above. I am sorry I only understand this thing half. ... Can 'value' be removed? Everytime I work on a web form, the same qeustion kept throwing back to me. Is there any attribute one can saftly remove without causing browsers, screen reader and form script suffer? label and ID are needed, Name also needed for the form script I use; this leaves the 'value' which I never able to decide the *value* of its usage. I really find a markup like this is too much label for=myformMy form /label input name=myform id=myform value=myform I think you are confused :-) There is a difference between label the html _element_ and label the _attribute_ on option and optgroup element: label for=myformMy form /label input name=myform id=myform value=myform attribute select id=myselectoption label=mylabel value=myvaluestring in option/option/select The 'value' attribute on option (and other form controls) is required for back-end processing (so that your script knows what to do with all the stuff the form feeds it). The 'label' attribute is always optional and _can_ be used by the UA for display purposes. 'name' is also required to identify the form control. 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] Encoded mailto links
On Oct 19, 2007, at 5:19 AM, Dejan Kozina wrote: Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. running OS X 10.4.10 + Mail.app * WebKit latest build + Safari 3.0beta + Safari 2.04 : opens a new mail message; page stays where it was (no redirect). * Camino 2.0a1pre/Minefield + Fx 2.0.0.8pre: open a new message/ redirect to a page [1]. * Opera 9.5 alpha: bugs me about choosing an email client, but then opens a new mail message and stays on the page (no redirect). * iCab 303: opens a new mail message and stays on the page (no redirect) * IE 5.23 Mac: opens a new mail message, no redirect. [1] http://www.kozina.com/mailtest/example/com/me Found The document has moved here. I don't know enough about 302 code to know if this could be a correct behaviour or not. 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] Catch 22 list problem
On Oct 13, 2007, at 10:10 PM, Jens Brueckmann wrote: I prepared a short example at http://lairx.de/071011/numbering- lists.html Triggers strict mode in Firefox - what about MSIE, Opera, Safari, etc? Opera 9.23/Win32+Linux and MSIE 6 SP1 both render in strict mode as well. I do not know about Safari though. Safari, WebKit, Konqueror 3.5.7 : Strict mode. iCab: I'm not sure. Its error console says 'unrecognised doctype', and my bookmarklet doesn't work in iCab. But I think Strict mode (that would make sense for an unrecognised doctype). IE Mac: Quirks mode. 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] Catch 22 list problem
On Oct 12, 2007, at 4:42 AM, Keryx Web wrote: A. li value=3 is not allowed in strict HTML 4/XHTML 1.0, Spec says use CSS. B. I want to start at 3. C: CSS has no means to specify a start value! Pick your poison: 1. Invalid code 2. Use a transitional DOCTYPE 3. Set value with DOM-script I'll choose: 1. Invalid code. No doubts. The start attribute also makes a come-back in html 5: http://www.whatwg.org/specs/web-apps/current-work/multipage/section- lists0.html#lists0 http://www.whatwg.org/specs/web-apps/current-work/multipage/section- lists0.html#start0 iirc, there was also a discussion in the html-wg to bring the start attribute back in the errata's for html 4.01, but obviously nothing came to that, and I can't find it in the archives. List numbers are 'content', after all is said and done. Browser- makers are moving towards using CSS 'counters' to generate the list numbers as an internal mechanism, but it does not take away that those numbers are content. (and CSS counters is a very attractive mechanism to control/alter the presentation of those numbers). 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 problem
On Sep 28, 2007, at 2:43 AM, Bas V wrote:
So far no problem... however, in Firefox, Internet Explore etc, the
y-scroll bar shows on PC and Mac but in Safari it doesn't show the
box's scroll bar, why
Here is the code I am using:
In the style sheet:
#photos {
...
overflow-y:scroll;
overflow-x:hidden;
}
Safari 2.0 and older do _not_ understand overflow-y and overflow-x.
It is not part of CSS 2.1, but in a draft CSS 3 module.
Afaik, Opera 9.23 and older do not understand that either.
You could try:
#photos {
overflow:auto; /* providing fall back for older browsers */
overflow-y:scroll;
overflow-x:hidden;
}
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+Voice
On Sep 8, 2007, at 9:32 AM, Tee G. Peng wrote: It's showing up on Opera site, so I reckon it's supported for 9.50 Alpha? And Safri Beta 3 too? http://dev.opera.com/articles/view/xhtml-voice-by-example/ That page doesn't work as described on Safari, seen from here (latest WebKit nightly build -OS X) and Safari3.03beta - both OS X and WinXP). But Mac OS X 10.4 (and esp. Safari) has build in screen reading technology: VoiceOver. Turn VoiceOver on (command F5), and you can have the page read to you. See [1] for a quick howto. No need for special (x)html code. iCab also has this option (from the View menu). Firefox and Camino nightly trunk builds will have support for VoiceOver in the future (currently you'll need to make a custom build from the Gecko 1.9 trunk to enjoy it. Basically, it works, but there are still rough edges. In a Camino build, it only works on the chrome part at the moment, not on the content part.). I tried that page in Opera 9.5 alpha, but it didn't seem to make any noise. But maybe I'm missing a setting somewhere. I haven't read much about that issue, yet. Opera 9.5a also seem to have basic support for VoiceOver (again, chrome only, as far as I could test). [1] http://www.456bereastreet.com/archive/200505/ voiceover_and_safari_screen_reading_on_the_mac/ 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 bug on CSS white-space property
On Aug 29, 2007, at 10:47 AM, Kepler Gelotte wrote:
I don’t think it is a bug. First of all you are not overriding the
white-space property buy assigning it to child elements or parent
elements.
You just create a conflict. Then precedence takes affect. According
to the
CSS2 spec:
'white-space'
Value: normal | pre | nowrap | inherit
Initial: normal
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual
Since you applied the “white-space: normal” to a span element
which is not
a block-level element it is ignored. By changing the span to a
div *or*
adding “display:block” to the span’s style, you will get the effect
you were
expecting.
But in the testcase, the white-space property is applied to the a
(in the head: a {white-pace:nowrap})
Firefox 2.0.0.x should _ignore_ that as well.
Anyway, my Gecko trunk builds (Minefield 20070828 and Camino trunk
build) correctly wrap the text the same way Safari and WebKit wrap
the text (ignore the white-pace:nowrap).
So Firefox 3.0 will display correctly.
And if the link text were to long for the space allowed by the table
(e.g. a very very long word), the table should expand, unless the
table has 'table-layout: fixed' 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] Firefox bug on CSS white-space property
On Aug 29, 2007, at 12:43 PM, Kepler Gelotte wrote: And if the link text were to long for the space allowed by the table (e.g. a very very long word), the table should expand, unless the table has 'table-layout: fixed' specified. The table should expand even though he specified width=175? I learn something new every day. Try this: http://dev.l-c-n.com/_temp/wp.html And yes that is the expected behaviour. 'Width' on table and td/th is more like 'min-width' (idem dito for 'height'). 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 display issue : help please!
On Aug 24, 2007, at 9:44 AM, Kit Grose wrote: I can fix it two ways: - wrap the form in a div - remove the display:table; rule on the enclosing div neither of which are very palatable in the context of the site. Hi Andrew, The issue is that you can't technically use the display: table property that way. Yes, you can. Per http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes an UA will/should insert a table-row and table-cell element. But Safari 2.0.x is buggy in this (and Gecko -Firefox- is buggy the other way around, sometimes inserting too many table-rows). The best solution is 1. use another technique to generate a new block formatting context on the div where you currently use display:table. Using 'overflow:hidden' is a better solution in many cases. 2. or: wrap your form in an extra div. I'd go for the first solution, as it will avoid potential issues with Gecko browsers. 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] Cross platform line-height?
On Aug 17, 2007, at 10:07 PM, Paul Collins wrote: Just wondering if anyone here has ever found a way of achieving a consistent line-height for Windows and OS X? Been searching for a while and can't seem to find the answer... For a given font[size][face] you'll get consistent results using length (e.g. 1.5) across a wide range of UA's that support the css 1 and css 2.1 font-properties. Consistent doesn't mean that all UA's on all platforms will display a line-box at exactly the same pixel size. Different platforms have different (raw) font-metrics, different UA's use different methods for rounding off numbers, etc. What exactly is your problem ? 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] setting fontsize in body
On Aug 8, 2007, at 6:45 PM, Rob Kirton wrote: However I would have thought it sufficiently an important feature to dedicated a couple of buttons in the chrome bar to it, maybe a simple + and - (my actual sugestion to them). What makes you think that there won't be 'a couple of buttons' ? The feature (page zoom) has only been implemented for 2 weeks, and there is no GUI for it, yet. You can track the discussion about the UI aspects: https://bugzilla.mozilla.org/show_bug.cgi?id=389628 [...]To most users it is a moot point whether or mot these buttons perfrom text resizing or indeed page zoom. That I'm not sure. I, for one, would hate to loose the *text* zoom feature. Page zoom doesn't really work, for me (and I'm not alone). But that features (and there associated UI) to improve readability of a page is important, that we all agree. And those features will become ever more important (more 'old' eyes on-line, increasing screen resolutions). 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] setting fontsize in body
On Aug 4, 2007, at 10:45 AM, Gunlaug Sørtun wrote:
Back to Tee's problem with 'body {font-size: 62.5%}' etc in Opera/
Mac. It may be caused by the preset value for 'minimum font size'
in that browser/OS.
If someone can check the preset value for 'minimum font size' in an
unaltered Opera/Mac, as I set mine to '14px' years ago and have
since just updated it, and I can't remember the preset value. Now I
can't even check Tee's problem, because my Mac is off-line.
Unless my copy is sick, the default is 9px.
I did notice sometimes that Opera Mac (and maybe Win) tends to round-
up decimal percentage points more aggressively than other browsers on
my Mac(s). That is more often the case in a complex cascade (e.g.
starting at 85.5% font-size, then a descendant has 90.5%, etc). I've
seen Opera round the numbers upwards more often (that is not more
than 1px per step, but can add up for deeply nested 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] (Phillipe) margin problem in Firefox
On Jul 20, 2007, at 11:27 AM, Tee G. Peng wrote:
Phillipe wrote in CSS-D:
It is a bug in Gecko. [1]
Here is your list, simplified.
http://dev.l-c-n.com/_temp/moz-egde.html
The top one is wrong, the bottom one is fixed.
li.poster {-moz-float-edge:content-box;}
does all the magic.
(one could argue about the semantics of your list construction,
but css-d is not the place for that).
For reference, this is the post on CSS-D
http://archivist.incutio.com/viewlist/css-discuss/90611
OK Phillipe, please tell me what I did in-correctly with this
construction.
(1) The List not being semantical for the comments markup?
A list is perfectly appropriate for comments - I use it myself.
That was not my point, actually.
[...]
(2) The P inside the LI ?
Added P tag for the comment message because there will be people
leaving more than one paragraph of texts and I don't want a break
in between.
(3) The numbering should be placed inside the 'poster' class
instead of giving its own class?
I think placing the numbering inside the li.poster class is more
appropriate, but I don't want to do that because adding a new LI is
more straight forward and easier to position the mustard box :)
Did it with a guilt but decided to go lenient for myself. Now you
mentioned it, I feel very bad and uneasy even without hearing what
you are to say
My problem with using a li just for adding a number to the comment.
I understand what you're trying to do - styling the list number for
the comment, which, out-of-the-box and with current css specs, is not
possible. (css3 makers/generated contents would allow many
possibilities).
I would use the following structure:
ol
li
h6span%number/span John Doe on Jul 7, 11:34 AM/h6
pcomment here/p
!-- or more p --
/li
substitute an appropriate level of heading for your needs
float the span, adjust margins to taste
That is about what I do on this now-defunct site :
http://emps.l-c-n.com/articles/94/widgets-for-firefox
(and that uses Texpattern behind the scenes).
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] Shadow validation
On Jul 10, 2007, at 10:36 AM, Dean Matthews wrote: I thought I was dense but now I think the W3C is just behind the curve ;-) Not really, just chose the appropriate options (advanced...) when you try to validate a file. 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] scope, cols and colgroups
On Jun 28, 2007, at 11:17 PM, Chris Price wrote: I thought I had scope, cols and colgroups figured out until I built a table that clearly showed that I hadn't. I have built a simplified table that illustrates this at http:// choctaw.co.uk/tabletest/ I want all all min columns coloured green and max columns coloured yellow but more than that I want to know where my logic has gone wrong. Your page is invalid. 1. a colgroup cannot be nested in another colgroup http://www.w3.org/TR/html401/struct/tables.html#edef-COLGROUP is not really clear. The html5 draft can help: http://www.whatwg.org/specs/web-apps/current-work/multipage/section- tabular.html#the-colgroup 2. you have a xml syntax in there: colgroup / colgroup is _not_ an empty element, it cannot use self closing syntax. 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]shorthand doesn't work for bg position (was auto-hiding bottom part of bg image when resizing fontsize
On Jun 20, 2007, at 3:57 PM, Tee G. Peng wrote: Strange! it really doesn't work for me for my testing in Safair, Firefox and Opera. I tried placing 'fixed' before and after the 'no-repeat', also after the x/y positions. Here is the test page: http://project.lotusseedsdesign.com/wandahennig/index2.html There is a fixed background image (a sepia-toned image of a lady) on that page. There are no problems with the order of values in the shorthand declaration. See the syntax in: http://www.w3.org/TR/CSS21/colors.html#propdef-background But don't forget that 'fixed' means fixed to the viewport. 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 2.0?!
On Jun 20, 2007, at 5:20 AM, Nick Fitzsimons wrote: PS - on OS X, of course. The beta download comes with an uninstall package to roll you back to your previous version of Safari. It's on the Safari3Beta.dmg you originally installed from. You can use the nightly WebKit builds to check out your documents in what will ultimately be Safari 3.0. Those nightly builds can co-exist nicely with Safari 2.0. http://nightly.webkit.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] Difference between IE and Firefox - can't figure it out...
On Jun 15, 2007, at 10:12 AM, Taco Fleur wrote: I'm hoping someone can see the obvious on the following page and tell me where I've gone wrong; http://vasco.brucehighway.com/reports-hierarchical-display.htm in Firefox it displays the totals on the right-hand side exactly where I expect it to be. In Internet explorer the numbers are aligning to the document and not to the relative positioned elements as in Firefox. Internet Explorer (6 but I've seen 7 acting up as well) doesn't know where 'right' is. It always computes that based on the nearest container that 'hasLayout' [1] and is positioned. In your case, I think it is body (I haven't gone through all of your stylesheets). giving the parent p 'layout' _might_ solve the issue. Why not a table ? [1] http://www.satzansatz.de/cssd/onhavinglayout.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] Difference between IE and Firefox - can't figure it out...
On Jun 15, 2007, at 12:26 PM, Taco Fleur wrote: I'm not sure what giving the parent p 'layout' _might_ solve the issue. means though? Maybe this translation works better: Triggering 'hasLayout' on the parent p _might_ solve the issue 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] Difference between IE and Firefox - can't figure it out...
On Jun 15, 2007, at 1:30 PM, Taco Fleur wrote: What do you mean by 'hasLayout', I don't use that as a class or id name and I have no idea what else it could be? Probably the only person who doesn't get it, sorry... Read the link in footnote [1] in my first message. It is only 45 printed pages long. [1] http://www.satzansatz.de/cssd/onhavinglayout.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] Mac test please (was Safari now on Windows)
On Jun 12, 2007, at 5:02 PM, John Faulds wrote: Well, as you mentioned it: I downloaded Safari for Windows today and didn't have any problem with it except that my own site looks completely screwed in it. It didn't look like that last time I checked with Browsercam and it doesn't look like that using Swift so I'm wondering if it might be a Safari 3 issue (and maybe just Safari for Windows). You declare a width of 600px on body. Yeah, and, you load stylesheets via xml PI. Safari/WebKit doesn't recognise media types in that case. It applies all your stylesheets. (try to convince your boss to by a Mac) 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] Mac test please (was Safari now on Windows)
On Jun 12, 2007, at 9:34 PM, John Faulds wrote: Yeah, and, you load stylesheets via xml PI. Safari/WebKit doesn't recognise media types in that case. It applies all your stylesheets. Yep, that was it. Thanks for that. But I'm curious why it's only a problem in v3 and not earlier versions. Probably because Safari v2 gets text/html for your site. The same bug is present there, though. - I'm just guessing, I don't have Safari v2 installed (v3 overwrites v2) on my PowerBook right now. I suppose you do some detection based on q values for application/xhtml+xml or similar. And Safari v2 only broadcasts text/html in the headers. 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] layout/font site test - please
On Jun 5, 2007, at 8:09 PM, Designer wrote: ... the htmlbody is ignored by all except IE6 I hope this is a typo. IE 6 ignores this (and NN4 in case you worry) as it doesn't understand the '' selector. All other browsers, including IE 7 support the child selector. 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] Re: Use of Fieldsets other than in form?
On Jun 5, 2007, at 10:19 AM, Jackie Reid wrote: Quick question for you lot. Can fieldsets only to be used in forms or can they be used to group any sort of related information together (ie: business name, short description, logo and link). In HTML 4.0, the description of fieldset can be found under the heading '17.10 Adding structure to forms: the FIELDSET and LEGEND elements' http://www.w3.org/TR/html401/interact/forms.html#edef-FIELDSET That makes quite clear that fieldset is intended for forms only And it is all part of chapter 17, 'Forms'. 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 positioning help needed
On Jun 3, 2007, at 3:04 AM, kevin mcmonagle wrote: heres the url with the styles at the time of the screen shot http://www.eaf.textdriven.com In Safari 2.0, WebKit, Gecko nightly builds (Mac), your gradient is covering the right hand scrollbar. That makes it impossible to use the bottom scroll arrow, or the thumb when one has scrolled to the bottom of the div. It 'works' in Firefox 2.0.0.4, but that is actually a nasty bug with Gecko Mac scrollbars - bug that is fixed in nightly builds. Screenshot: http://dev.l-c-n.com/_b/kmcm.png 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 hack for overflow-x/y
On May 31, 2007, at 10:04 PM, kevin mcmonagle wrote:
So i want safari to see
#wrapper
{overflow:auto;}
And I want all other browsers to see
#wrapper
{overflow-y:auto;}
Safari hacks seem to be semi-permanent because when they are found
they are fixed in the lastest version or build of webkit and the
new version of safari is coming out soon.
#wrapper {
overflow:auto; /* for Safari, older versions of Firefox, Opera,
other browsers that don'ts support the css 3 syntax */
overflow-y:auto; /* Firefox 2.0+, IE 5.5+, Safari 3.0-Webkit-
Konqueror4.0 */
overflow-x:hidden; /* depending on your set up...*/
}
You need to keep them in that order, what comes later in ruleblock
overrides what comes earlier.
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] Converting font size from pt to % or em
On May 26, 2007, at 11:16 AM, Paul Novitski wrote: Do you mean no elegant way to scale them in a user stylesheet or no elegant way to scale them in real time, e.g. with a mouse wheel? I have my minimum font-size set to 12px [1] (Gecko browser), or sometimes 14px (when I'm tired, and really p*** by mouse type and the need to zoom in way to often) * No elegant way to scale the whole thing correctly in a user stylesheet, short of rewriting the whole author stylesheet [2]: with the 62.5% 'trick', the base for all computation will be 12px in my case. Say I reset the font-size to 16px for a particular site (using @-moz-document), all scaling in that author style-sheet will be oversized, as I thing Christian explained). * No nice way to zoom out in real time, due to the clash between minimum font-size and the author specified miniscule base. [1] that is my minimum font-size, below which I cannot read text. It is _not_ my preferred font-size. [2] user stylesheets are already a pain for the average user, image if they have to rewrite the author stylesheet completely... (even for me it would be serious nuisance - and I have a 3000 lines long user stylesheet) --- While in theory, I, as a user, should like that method of setting font-size - combined with my minimum font-size is should guarantee readable text, in practice it is a pain: many more sites break (even some where e.g width is set to ems or the like), or quickly become way to wide for my preferred window width. 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] width of inline lists
On May 20, 2007, at 9:02 PM, Designer wrote:
Has anyone got a (simple) workaround for the fact that I want to
specify the width of each li in an inline list? (which is not
allowed).
I'm using the simple menu:
div#menu {
font : 13px Verdana, Arial, sans-serif;
text-align : left;
color: #333;
}
div#menu li{
width : 250px;
display : inline;
list-style-type : none;
}
[...]
and, of course, the 'width : 250px' is just ignored. I've tried
setting a width on the a but that doesn't work either.
MUST I use a table?
Obviously:
li {float:left} ?
or li {display:inline-block } ?
The second one won't work in Firefox up to 2.0.0.x (but will work in
Fx 3)
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] While we're on the subject of validators...
On May 1, 2007, at 2:40 PM, John Horner wrote:
Well perhaps your second point is valid (and well formed) but this
example:
body { background: url('image.gif')no-repeat top }
isn't just about cross-browser compatiblity. Surely without the
whitespace, it's actually invalid CSS? The same as it would be if
no-repeat and top appeared without space between?
I don't think it is invalid CSS - the closing parenthesis ')'
terminates the url value. The white-space is optional. I think.
For keywords, it is of course different 'top right' is not the same
as topright.
See for more:
http://www.w3.org/TR/CSS21/syndata.html
And as for the logic of HTML tags, it would undeniably be a better
validator if it could warn tag-based declaration doesn't match any
known HTML element, the way Perl's error reporting warns me about
variables I've created but never used, on the basis that it's
probably a
typo.
The validator doesn't look/care about what you put in a selector.
What if you are using that css file for some xml document that has an
element 'navbar' within its namespace ?
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] Template Review
On Apr 30, 2007, at 10:04 AM, CK wrote: http://working.bushidodeep.com/dom_site/template.php In random order: more white-space (everything is like squished together). as Paul mentioned: why the pointer over the dt/headings ? the letter-spacing on the dd is annoying. It is a bad idea to letter- space body text - font-designers do know their stuff, you know. Might work well on your machine, with your fonts/font-size. On my browser (Gecko trunk, OS X 10.4.9), with my font-size, I see all characters drifting apart. combining fixed width on a container and then setting a max-width in em inside (your dd) is problematic. use sans-serif fonts for headings and serif fonts for body text (like the dd, again) will create some more visual structure. 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] strong v's b , em v's i
On Apr 23, 2007, at 4:23 PM, Mordechai Peller wrote: The site is wrong, plain and simple. b and i ARE depreciated, while strong, em, and blockquote are certainly NOT. Also, the size and type attributes are also not depreciated. deprecated... [1] And no, neither b nor i are deprecated; or strong and em. When in doubt, ask the official docs: http://www.w3.org/TR/html401/present/graphics.html#edef-B http://www.w3.org/TR/html401/struct/text.html#edef-STRONG note also the html5 proposals: http://www.whatwg.org/specs/web-apps/current-work/#the-b [1] http://hsivonen.iki.fi/wannabe/ 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] making tables/rows/cells in IE lose their tableness via CSS
On Apr 17, 2007, at 5:21 AM, Patrick H. Lauke wrote: I'm just at the beginning of a little experimentation, and already IE stumps me. Basically, trying to use a table in markup but hide one column and make the other fall apart into individual inline cells. Try as I might, though, IE doesn't seem to lose its desire to show the cells as a table. Any thoughts? http://www.splintered.co.uk/experiments/archives/tagcloud_table/ index.html I once tried the same exercise, but using 'inline-block' in stead of 'inline'. Failed. The only thing that would work is using position:absolute on the table-cell, but then you'd need to position each one of cells via 'top' and 'left'. 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] opacity
For a little while, I went down the path of opacity: 0.5; but quickly found that nothing could be done to reverse the effect for children of the object - they all went wishy washy too! That is the expected behaviour. opacity [1] applies to the whole box (and its descendants), it is _not_ about making the background transparent/translucent. What you want in that case is using rgba() or hsla() colours [2]. rgba() is supported by Safari and I think Konqueror (can't test on my set up). hsla() is supported by Webkit, I think by Konqueror, and by nightly builds of Gecko. actually I've been having problems with opacity with text too... fine in Firefox but IE doesn't seem to recognise it. IE doesn't support the opacity property. It only supports a proprietary property [1] http://www.w3.org/TR/css3-color/#transparency [2] http://www.w3.org/TR/css3-color/#rgba-color 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] Odd behaviour in Opera and Safari
On Apr 10, 2007, at 11:05 AM, Rachel May wrote: This site http://skylight.web1.heliocell.com/professionals--community- groups.aspx (please note still in testing, so e-commerce transactions won't go through, etc.) is having odd behaviour in Opera and Safari - the page headings are going small after the page is loading. This is causing the search box to overlap the navigation (the logo is in an H1 tag). Also in Opera, the links are going red. That happens more often when one of the required css files is not found. In your case, you are linking to 'http://skylight.web1.heliocell.com/niftyCorners.css' (from within your script[1]), but that file returns a 404not found. The IIS 404 file has some css into it, although its content type is text/html Opera and Safari interpret the file nonetheless and apply the stylerules in that 404 page to the real html page, hence: red links and smaller type on your heading and who knows what more. Yes it is a bug in those UA. That is what you get when a UA accept whatever content-type one throws at it and try to interpret it. Gecko based browsers simply ignore that missing file completely. [1] function AddCss() in script.js 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 won't repeat-y
On Mar 5, 2007, at 2:28 PM, Christian Montoya wrote: I'm almost certain that you need the positioning in that shorthand to make it work: background:url(some image) left top repeat-y; or center center, or anything really. No, you don't need. With shorthand, properties that are not specified assume the default (in this case top left or 0 0) 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] playing with layouts, pt2
On Feb 26, 2007, at 6:50 AM, Gunlaug Sørtun wrote: Designer wrote: I don't understand that. If Safari is capable of handing the correct mime type, how can (why would) it serve 4.01 strict? Probably because Safari is cheating :-) Not really. Safari's Accept Headers: Accept: */* translated: 'I prefer text/html' The latest Webkit builds report this: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8, 1: Don't think Safari has a genuine xml-parser. Suspect Safari to use the same parser as for 'text/html'. Don't think so. But just as with other browsers, the xml-parser is much weaker and prone to bugs compared to the html parser. Note also: Safari only knows about the five required named entities. If you use other named entities, Safari will report an error. (Gecko and Opera know internally about about most named entities). Use numerical entities instead. 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] Odd FireFox div background image behavior
On Mar 19, 2006, at 6:35 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Test site: www.designbyatfb.com/designs/golfintro.html
The background-image in the
}
#containerDiv{
position: relative;
top: 0px;
width: 800px;
margin-top: auto;
height: 100%;
color: rgb(128, 128, 128);
overflow: visible;
background: transparent url(css-images/swing.gif) no-repeat ;
background-position: bottom;
}
disappears when the page is resized in Fire Fox v 1.0.7 and Mozilla
1.7.12. It does not even appear at all in Opera 8.02
If page is opended at 800x600 it is fine. If it is opened at
1024x768 or higher, it is fine.
If you resize after the initial view it disappears until your
refresh. I have tried different Doc types, and encodings, nothing
makes any difference.
it simply never appears on my side (Firefox 1.5, Camino 1.0, Safari
2.03, Opera 9 TP2). And that is correct.
Your #containerDiv is pretty much empty, because it mainly contains
two floated blocks, which by definition are taken out of the flow.
That #containerDiv collapses in height, and hence can't show your image.
And no, your 'height:100%' won't do anything, as it is impossible to
calculate that height, given that no height has been specified on any
parent.
It happens to wrok in IE windoze, because declaring a height in that
browser gives the element 'layout' [2], and contains the floated
blocks.
#containerDiv {display:table}
will fix your problem, by establishing a new block formatting context
[1], which will contain your floated blocks.
[1] http://dev.l-c-n.com/IEW/simulations.php
http://www.w3.org/TR/CSS21/visuren.html#block-formatting
[2] 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] CAPS in stylesheets
On Mar 13, 2006, at 5:14 PM, John Wells wrote: Can we get a summary of this CAPS lesson? Are we saying that: - ONLY when serving XHTML as application/xhtml+xml, stylesheet selectors must be all lowercase. ? Some browsers are sensitive to case when XHTML is served as text/ html. iCab comes to mind. Having said that, I'm a bit confused. I wish I could remember where I read this, but I thought that *technically* (that's how I remember it being phrased) stylesheet selectors should not contain characters other than alphanumeric (and must start with a letter). Well once I read that, I moved all of my selector naming to camelCaps...so now I'm feeling squeezed. In (properly served) XHTML can I use underscores to separate my words? I strive to make my code as readable as possible (from CSS to PHP), so naming conventions are a bit of a sticking point. Why not ask the source ? http://www.w3.org/TR/CSS21/syndata.html#q6 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] Absolute Positioning-A Naive Question (Maybe)
On Mar 14, 2006, at 11:35 AM, Paula Petrik wrote:
When I read the W3C specs (not the most riveting exercise on the
planet), it seems that the developers emphasize absolute
positioning. For example, they describe using floats to float small
bits of text or images. It seems, however, that floats have become
the order of the day. Rather than small bits, whole parts of
designs are floated about. Was this the W3C's intent? Or, have
floats become the modern equivalent of tables? Is there some reason
why absolute positioning has fallen by the wayside? CSS-Discuss's
wiki describes absolute positioning as capable of simple designs;
yet, a significant proportion of csszengarden designs are
absolutely positioned, and I wouldn't term them simple. Just
wondering what the current wisdom is on this issue.
You read that correctly, and Felix already pointed you to that
article by David Baron.
The main reason that 'floats' are so popular in current css driven
design: they are currently, and very unfortunately, the best tool
available for the job of creating multicolumn designs.
Absolute positioning has one problematic side effect: as the height
of the column is usually unknown (depending on the contents), it is
more difficult to position an element under that absolute positioned
element. Not impossible, mind you, with a little help of javascript.
An alternative would be the use of {display:table} and {display:table-
cell}. But that is not supported by IE, which puts serious limits on
the technique.
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] IE Reverse Indent ?
On Mar 8, 2006, at 2:51 PM, Jason Turnbull wrote:
http://www.hudsonantiquecarclub.com/index.html
IE6 adds an reverse indent just under the header Monthly Meetings
(Paragraph starting Rudy's...)
Is this to do with the thumbnail to the left?
Known as the 3 pixel text-jog
http://www.positioniseverything.net/explorer/threepxtest.html
Easily fixed by adding #content_home to the IE specific style you have
already:
ul a, ul, li, #content_home {height: 1%;} /* Holly hack fix for IE
bugs */
That is a bit radical... giving all those element 'layout' can
possibly cause more problems than it fixes.
In this case:
/* - hide form IE Mac - \*/
* html #content_contain {height:1%}
/* - end hiding - */
ought to do nicely.
(and served only to IE 6 and below. That 3px jog thing is reportedly
fixed in IE 7 alpha0).
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 Fieldset and Legend Elements
On Mar 8, 2006, at 2:48 PM, Lachlan Hunt wrote: Thierry Koblentz wrote: I think it worth mentioning that the * html hack works in IE *Mac* too. What about conditional comments? I don't think that really matters much anyway, since IE Mac is officially obsolete (i.e. now completely unsupported by Microsoft) and ... It might be unsupported by MS, but it is still quite well used, in the **real** world. That said, no, IE Mac doesn't support CC. I think some unwanted hacks applying to it would be the least of its problems. Let it see some of the hacks targeted at IE Win can end in a complete disaster (i.e. inaccessible content). The often used 'Holly Hack' (height:1%) causes big problems in IE Mac. That browser incorrectly computes % height as '0' instead of 'auto' as it should per CSS 2.1 (for in-flow elements when no parent element has a height 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] Styling Fieldset and Legend Elements
On Mar 7, 2006, at 2:12 PM, Lachlan Hunt wrote: I'm looking for a way to style a legend element with a background that spans the whole width of the page. I originally used a regular heading (h3) because I knew the design would have difficulty with fieldset/legend, but the after the accessibility review it was requested that we use fieldset/legend anyway and I need to get the design as close as possible. By default, legends are only as wide as they need to be to fit the text and there seems to be little one can do about this in current browsers. I came up with one solution using a thick top border on the fieldset behind the legend element which works in Firefox, but it doesn't quite work in IE because it leaves a small white gap between the legend and fieldset border. I currently don't have access to any other browsers for testing, but I'd like it to work fairly well in at least all major browsers. The following test case demonstrates how I want it to look and my current solution that works in Firefox. Both examples in the page should look roughly identical http://lachy.id.au/dev/2006/03/fieldset On OS X 10.4.5 Firefox 1.5, Camino - latest nightly trunk build, iCab 3.0, Safari 2.03 and WebKit nightly build, Opera 9 tp2, all look the same. and so does Konqueror/KDE 3.5 running on top of OS X . IE 5.2 Mac has a small 1px white border around the legend, barely visible given your light background-color. There is also some white- space under the legend (padding on fieldset, you won't get rid of 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] making table cells share equally
On Feb 22, 2006, at 8:10 AM, Ted Drake wrote:
If I have two or three columns in a table and I want the cells to
share the
space equally, what would you suggest? I don't have a width on
these cells
right now and if one cell has lots of content, it's pushing the
other column
to the curb.
table {table-layout:fixed; border-collapse:collapse; width:xxx}
http://www.w3.org/TR/CSS21/tables.html#propdef-table-layout
according to the rules, a width on the table need to be specified; IE
Win will default to 100% if no width is set.
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] TARGET in 4.01 Strict
On Feb 16, 2006, at 5:58 PM, James Bennett wrote: I was being somewhat facetious, but every browser I have within arm's reach (which includes all the popular browsers except Safari -- I don't have a Mac here at home to refer to) implements some form of extended Back functionality which displays a list of all the previous pages for the current window/tab and allows any one of them to be selected. Safari has this same functionality: onclick= 1 step back; onmousedown= popup menu with your recent widow history. I'm not sure how many steps it remembers, I never use Safari except for testing. Even then, there is the History (Go in some other browsers) menu to help the user out. 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 Labs and Opera 9 Preview 2
On Feb 8, 2006, at 4:11 pm, heretic wrote: Maybe the standards community prefer to ride ponies instead of real race-horses? ;-) Must be something to do with keeping nearer the earth. Opera spoils web developers, and makes Internet Explorer (and Firefox, to a lesser extent) that much more shocking ;-) hehehehh ahhh dear, we're the mac users of the browser world aren't we ;) [grabs his fireproof suit] speaking of macs, i wonder if the new mac version of opera will change the stuff that angered joe clark? [http://blog.fawny.org/2005/02/01/opera/] i don't have a mac to try it out. Hmm, if they could clone the interface of Omniweb (they already cloned a couple of features) or Camino, it would become a very nice browser. - granted, they did make some serious progress with Opera 9 (tp1 and tp2) Part of Joe Clark's issues are fixed. But the UI design still feels like poor. The 'looks' are still out of place and Windoze like. That said, to stay on topic, with the latest release, they've made good progress in fixing their rendering bugs. A whole bunch of margin-collapse bugs are fixed, quite a few issues with relative positioning as well. And speed is back, on Mac at least (tp 1 felt more like one of those big heavy duty horses used in the fields rather than Georg's race horse. 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] Re: Multiple language usability query
On Feb 7, 2006, at 5:08 pm, Andrew Cunningham wrote:
Also worth noting, with CJK text, in the absence of css specifying a
font, the browser will chose the font based on langauge of the text.
If the language of the text is not indicated then IE will try ot use a
Japanese font to display CJK, Opera uses a Korean font instead, and I
forget what Firefox does.
Firefox Win takes the fonts as specified in the browser preferences
(ContentFont colors advanced). If none is available (ie no
East-Asian language pack installed) then all madness is possible. As I
said, I've actually never seen what happens on a Win PC that lacks the
East-Asian language pack ('cause all PC's here in town have it
installed).
(hence, out of curiosity, if someone would be kind enough to send me a
screenshot of the file I posted earlier, that would be appreciated).
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] Multiple language usability query
On 7 Feb 2006, at 7:02 am, Sarah Peeke (XERT) wrote: I am new to multiple language sites. However, I have a client who has a small amount of text on one page of his site referring Japanese speaking users to a different (Japanese) site. Firefox and Safari on the Mac seem to have a default which allows the Japanese to be read. However, I noticed that good ol' Windows IE6 doesn't automatically render other languages and that its preferences needed to be changed etc. Japanese (and other East-Asian) language support is installed by default on OS X. Not so on Windows side of things (it comes with the install discs as an extra package). I've been told that Firefox/Win tries to display the text nevertheless. Lachlan wrote It's probably a font related issue. IIRC, if none of the fonts specified in the font-family property contain the glyphs for those characters, IE won't find and display them. You may be able to improve the situation by including the following: font-family: Arial Unicode MS, Lucida Sans Unicode, sans-serif; Hmm, not sure (but I can't test those things, I don't have access to a PC without East-Asian language support...:-)). A little test file http://dev.l-c-n.com/_temp/j-test.php Includes a screenshot. I've used a whole collection for the font- family (first some Japanese font-families, then some fall back stuff as mentioned). Let me know how it looks like (for the curious, it is my name). Sarah again My question is this: Since most web users are using IE, and I imagine most IE browsers do not have multilingual capabilities enabled, then they would see gobbledegook. So... How do we overcome this in terms of usability? Is there a standard? Should I include (in English) a title and/or link above the Japanese text explaining how to render the text below, or explain, at the very least, that the strange characters below are in fact in another language? What about including the text both in Japanese and English ? 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] Display:Table
On 5 Feb 2006, at 7:13 am, Al Sparber wrote: The issue: Imagine that all display values are supported by all browsers as of midnight tonight. LOL - still eleven hours to go on my side ;-) can't wait... Do you think that using display:table and display:table-cell to create multi-column layouts is correct or incorrect - and why? display:table/display:table-cell is certainly a good way to style content-blocks into multiple columns. Pro: it creates a structured grid that is easily controlled: new block formatting context for each column, various properties of table (table-layout, border-collapse, empty-cells, horizontal alignment), all with a minimum of mark-up; equal-height columns. Probably closer to the original intent of CSS as a styling language [1] Cons: bound to source order, some undefined behaviour (position:relative on table-cell [2]). It is already possible to create very consistent things across browser-land. Except, that is, in IE (win). Much less of hack than float based layouts. @Kenny Graham CSS's multi-collumns [3] is more about flowing content across multiple collumns, not really a layout technique for grid layout and grid positioning. There exist an interesting early draft about grid layouts: http://www.w3.org/TR/2005/WD-css3-layout-20051215 See Bert Boss message to the www-style list [4] [1] http://dbaron.org/log/2005-12#e20051228a [2] http://www.w3.org/TR/CSS21/visuren.html#propdef-position (pos. relative on table-cell is only supported by iCab 3.0) [3] http://www.w3.org/TR/css3-multicol/ [4] http://lists.w3.org/Archives/Public/www-style/2005Dec/0081.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] IE7 hacks
On 4 Feb 2006, at 3:25 am, Ted Drake wrote: I posted a hack to IE7 today. I know I'm not the first one to find this, but thought I'd throw it out there for all to love on. www.tdrake.net It's pretty simple. But please, think beyond hacks. I'll file a bug report for that parsing bug :-) 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] Check boxes ticked (UK Law)
On 31 Jan 2006, at 12:33 am, Paul Collins wrote: I recall reading somewhere a while back that UK law states you can't have a check box ticked on a form EG - untick this box if you don't want to receive emails would be illegal for a UK site. That would be European Community law, not only UK law. And yes, I believe this to be correct. You have to make this 'opt- in', default being 'opt-out'. 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 CSS issues
On 28 Jan 2006, at 3:09 am, Veine Vikberg wrote: Well Georg came with a suggestion that is working for Windows machines - now this design is close to what it needs to be on Windows IE/Moz/Opera. My issue is now Mac - I have a mac in the office (Strawberry iMac os 8.6 IE 5.1) and on that one all layout is virtually gone with the wind. All id and classes seems to be ignored, and they are thrown all over the place, stretching the page to a three screen horizonal scroll. I am at a loss to why this happens. The page is question is: http://jpfco.com/testdesign/new/ Your iMac runs old sofware... That site displays fine in Opera 9TP1 Mac, Safari 1.2 and 2.0, Firefox 1.5. Camino and Firefox nightly trunk builds have a problem, the side test (under the contact data) drops below the image. Nothing to worry about, it is a regression from a recent code base mod. IE mac has some more serious issues, at least one. It puts #content next to the #header, which is floated. Solutions: either add a clearing element between header and content, or just float:left #content. 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] Article: MIME and Content Negotiation
On 16 Jan 2006, at 11:53 pm, designer wrote: However, I remain confused in the particular case of the PHP approach. The PHP looks to see if(stristr($_SERVER [HTTP_ACCEPT],application/xhtml+xml)) and on that basis it describes the appropriate prolog, mimetype and charset. So the final three lines of the php code (where the action takes place :-) are: header(Content-Type: $mime; charset=$charset); header(Vary: Accept); print $prolog_type; That sounds very weird. Either your browser is acting up or something is not properly configured, or your server is doing something odd on the way. Is the $charset var set up correctly ? (near the top of the code) It should read: $charset = utf-8; 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 Lightening Entire Background Image
On 13 Jan 2006, at 9:18 am, Mani Sheriar wrote: I’m having a slightly maddening problem that appears to be only in Safari. The test page is here: http://www.manisheriar.com/sparkplug/paywi/ On Firefox and IE all seems good, but in Safari the grays of the main background image are too light and therefore clashing with other images where it is supposed to blend. See screenshot here: http://www.manisheriar.com/sparkplug/paywi/_images/paywi.png There is indeed a huge difference between the rendering of bg_home.jpg (the big one in the middle) and bg.jpg. See http://emps.l-c-n.com/bm/mani.png (this is on 10.4.4) I can reproduce this on 3 different machines. Latest Safari on 10.3.9 shows the same. Safari has known issues with png files (colour that doesn't match the same colour in htmls/css), but that is not the case here. Are all those images saved as the same compression level ? Could this be related to background-repeat: repeat or no-repeat ? I've never seen something like this with jpg files. PS - the problem only happens with Safari. All other browsers on OS X display the page correctly. 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] Jello Mold not working right in IE/Win
On 9 Jan 2006, at 9:18 am, Seona Bellamy wrote:
I've used the Jello Mold Creator at Position Is Everything to
handle the
sizing issues for the site I'm redeveloping. Seems to be working
fine in
Firefox, but when I opened it in IE I found that it was far too
wide. Ugly
sideways scrolling, content vanishing off the right side of the
screen, the
works.
I'm pretty sure that I took everything I needed from the Creator,
so can
someone please have a peek and see if they can figure out why IE isn't
behaving nicely?
Page: http://staging.renovate.com.au/
CSS: http://staging.renovate.com.au/_resources/layout.css
I haven't had a look at your page in IE win but noticed one thing in
the source code.
In your conditional comment, the width of the expression is set to a
negative % value. Don't think that is correct.
!--[if IE]
style type=text/css
#sizer {
width:expression(document.body.clientWidth 0 ? 280px : -28% );
}
/style
![endif]--
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] XHTML again
On 7 Jan 2006, at 3:35 pm, Lynne Pope wrote: On 1/7/06, Gunlaug Sørtun [EMAIL PROTECTED] wrote: It is not as easy to hide proprietary and 'not-yet-recommended' CSS from the validator, as it is with all the garbage often needed to make IE/win behave. OTOH: hiding something in a conditional comment (or in a 'non- existent stylesheet', like I do at times) doesn't make it more valid - just hidden. Conditional statements are not hidden, they just do whatever you code them to do. They are a valid markup. Conditional Comments are indeed valid markup. The point here is that, it is a comment, and anything within a cc it is hidden from (X)HTML compliant browsers. Only IE for Windows can take a peak at it. Thus yes, style within a CC is hidden from the validators. BTW: non-valid CSS doesn't affect HTML/XHTML status/validity at all. True. However, if we are coding to standards then it pays to be aware of any coding errors in css. You can't look at each standard in a vacuum. Whatever your css contains won't affect the validity of your (X)HTML. Then, to what Standards are you coding your CSS : CSS 2.0, CSS 2.1 CSS3 ? CSS 2.0 is a hopeless mess, CSS 2.1 is a bit better but still full of contradictions and undefined behaviour. The only part of the whole CSS thing that is pretty stable is the CSS selectors module. http://www.w3.org/TR/css3-selectors/ And when you validate a stylesheet, against what do you validate ? In my case you'd need to check against CSS 3, and even then, you better check against the respective docs (various versions) because the W3C validator doesn't know or support those (namespaces, mediaquerries, css-text amongst them). The text-justify property you mention in a previous message is included in one of those (draft) docs and currently only implemented by MS IE win. It does not validate at all as HTML 4.01 Strict - are you sure you are checking validation against that DOCTYPE? This sounds a bit strange to me. Which source-code should be checked as HTML4.01? Given the fact that the validator is fed an XHTML1.1 page with the correct MIME-type by default, is it even possible to check that source-code as HTML? I would think not. Enforcing the validator wouldn't work - and it shouldn't since the source-code isn't 'HTML4.01 Anything' when it's served to the validator. And your point is? I made the comment that the site does not validate as HTML 4.01, did you see me say how I validated it? Anyone designing a site to render as one DOCTYPE in some browsers and another DOCTYPE for other browsers, and who wishes to have the pages validate against both DOCTYPES would, I assume, check the validation for both. This can be done in many ways, such as entering the source code, or in cases where the person looking at the code is sufficiently experienced, just looking can show there are errors. I manually validated 3 random pages from Bobby's site: accessing the page with an older browser, copy the source code and pasting that into the textarea of my local copy of the W3C validator (@v 0.7.1): all validated correctly as html 401 strict. Georg point is: if you send a url to the validator, it will validate against xhtml, because that is the way the data is sent to it (with mime type application xhtml+xml). 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] Fieldset inclusions and possible Firefox bugs
On 5 Jan 2006, at 8:30 pm, Nick wrote:
I recently discovered this same problem and it is indeed a bug
within the
new Firefox. Unfortunately, no one's currently working on it which
means
that we're stuck using ugly solutions to fix it. I found that
wraping an
extra clearing container around the original within a fieldset
works. It's
definitely ugly but seems necessary at this point. So instead of
div class=clear/div
to clear two floating items within a fieldset, its
div class=cleardiv class=clear/div/div
or however you're clearing your elements. Adding that wrapper
container
seems to do the trick. I did manage to find a bug report of this on
the
Mozilla site here:
https://bugzilla.mozilla.org/show_bug.cgi?id=309550
Given that the OP use a definition list, there is a simple/clean way
to fix the problem caused by that bug.
Set the dl to {display:table}
http://dev.l-c-n.com/Gecko/fieldset-clear-309550.php
You may need to set a width on the dl to avoid shrink-wrapping.
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] XHTML 1.1 Entities (WAS Claiming compliance when a site doesn't comply)
On 6 Jan 2006, at 10:50 am, Kenny Graham wrote: List of XHTML 1.1 entities, served as application/xhtml+xml : http://www.w3.org/People/mimasa/test/xhtml/entities/entities-11.xhtml I really hope I'm right, or I'm gonna have to go back to a lot of sites to fix a lot of ldquo;s and such. If you want to support Safari (with application/xhtml+xml), I'm afraid, you'll have to go back... Screen shot from the page linked above (Safari 2.02 - latest Webkit nightly builds are identical): http://emps.l-c-n.com/bm/Safari-entities.png 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] XHTML 1.1 Entities (WAS Claiming compliance when a site doesn't comply)
On 6 Jan 2006, at 1:42 pm, Jason Turnbull wrote: Kenny Graham wrote: I really hope I'm right, or I'm gonna have to go back to a lot of sites to fix a lot of ldquo;s and such. Philippe wrote: If you want to support Safari (with application/xhtml+xml), I'm afraid, you'll have to go back... If these entities are not allowed when served as application/xhtml+xml shouldn't the W3C validator pick this up? Or has Safari got it wrong? Not really wrong. Firefox and recent Opera versions rely on the Doctype to parse the document as xml in addition to the mime-type [1], while Safari bases its parsing only on the mime-type. [1] this gives them additional knowledge about those entities. 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 FF hidden div still shows scrollbars
On 23 Dec 2005, at 3:21 am, Thomas Livingston wrote: Hi listers, We have a div being hidden (visibility:hidden;) and then using javascript to show hide layers (sort of a pop-up but not sorta thing). If we give it a height and apply overflow:scroll; (or auto) it looks and works dandy, except for Mac FF (1.5). We are still seeing the div's scroll bars when in it's hidden state. Anyone come across this before and fix it? https://bugzilla.mozilla.org/show_bug.cgi?id=187435 Try display:none, if that fits in your design. 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] Setting Up Font Sizes
On 21 Dec 2005, at 5:25 pm, Lachlan Hunt wrote:
Felix Miata wrote:
Lachlan Hunt wrote:
body { font-size: small; }
is generally acceptable and is approximately the same as 80% of the
Definitely not acceptable to me for content paragraphs. :-(
Why not? Is it too big or too small for you? Or is it just not
precise enough?
If you say it's too small, then I'd accept that. There are many
who say anything below 'medium' is too small for body copy. If you
say it's too big, then I have to very strongly disagree and say
that making it any smaller, will make it very difficult or at least
uncomfortable for many users to read without increasing it.
If you ask me and my tired old eyes:
Depending on which font-family you use, font-size:small is either on
the lower limit (georgia, which is a *big* font), or really too small
for me, when used with Roman fonts.
Using the same font-size:small for Japanese fonts/text on the other
side works pretty well across the board for me, except in Camino/
Firefox Mac, which tends to smash down fonts.
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] Browser Resolutions
On 16 Dec 2005, at 5:28 pm, Martin Heiden wrote: Our statistic of last week: [snipped] Those numbers refer to the resolution of the monitor, right ? What would this tell me about the size of the browser window ? That is what interests me. The user may or may not have the browser window open at full width of the monitor. The user may or may not have on of those sidebars open in the browser. That side bar may or may not be large. That makes those numbers pretty meaningless in my eyes. 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] Justify this
On 15 Dec 2005, at 2:15 pm, Al Sparber wrote:
If you're into justified text, the only browsers that can do a
reasonable job are IE5.5x+ Windows, using a proprietary property.
The programming is pretty darn good. It's nearly as good as the NY
Times, actually. But it ain't standards and must be deployed via
Conditional Comment. Take it and hide before somebody yells at us ;-)
!--[if lte IE 6]
style
p {
text-align: justify;
text-justify: newspaper;
}
/style
![endif]--
Those text justification properties from MS are quite nice. I use it
often for display of Japanese text. It makes Japanese text nearly
readable on IE (now if those MS fonts weren't so ugly,...)
p {
text-align:justify;
text-justify:inter-ideograph;
}
The text-align:justify also works pretty well in Firefox 1.5, for
East-Asian text.
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 1.5 is official
On 1 Dec 2005, at 12:36 pm, Zach wrote: Bah, problems already. When you use dead centering in CSS (i.e., background: url(picture) center center no-repeat;), it ignores the second center, even though it is perfectly valid CSS. Firefox 1.5 is correct according to css2.0. Firefox 1.07 was buggy in this. See https://bugzilla.mozilla.org/show_bug.cgi?id=243751#c4 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] shrink-to-fit width in Opera
On 21 Nov 2005, at 8:33 pm, Andy Budd wrote: One of my annoyances with Opera is that it calculates the shrink-to-fit width of absolutely positioned elements to be the minimum width, basically adding a break after each word. I wanted to write about how annoying this was, but thought I'd better check the specs first, just in case it was actually right. http://www.w3.org/TR/CSS21/visudet.html#the-width-property First, which version of Opera are you testing ? Second, what kind of content goes into that absolute positioned element ? If I put an element with just some static text in, Opera 7.5 - 9 prev display the same as Firefox (1.6a1 nightly), Camino (1.0b), iCab, Safari 1.2+. However, add a floated block in there, and then Opera is a bit more aggressive.[1] Put multiple floated blocks in the AP element, and Opera 7 behaves differently from others. That was a know bug in that version (not limited to AP elements, btw). The spec doesn't specify exactly what should happen; here is the key: quote CSS 2.1 does not define the exact algorithm/quote What exactly is a line break ? Does the end of a *floated* span constitute a line break in this context ? And if you start to play with more complex constructions, the differences between all (decent) browser increase, see [2] as one example. [1] http://dev.l-c-n.com/_temp/AP-shrink-to-fit.php [2] http://www.satzansatz.de/cssd/tmp/100307.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] Accessibility: Default placeholders
On 14 Nov 2005, at 12:22 pm, Geoff Deering wrote: *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. The problem with this is obviously that it's difficult to say *how* grey an input has to appear before a user thinks it's read only. Do we sit down and define a required luminescence/contrast to the background? In my mind, hard to quantify other than to say: be careful, don't make it too dark/grey, otherwise some users may think they can't use them. I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. 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] hiding legend tag
On 11 Nov 2005, at 7:47 am, Alexander Jerabek wrote:
So I came up with this:
legend{margin:-1em; font-size:0px;}
In Mozilla the 0px makes the text invisible, but only miniscule in IE
so
I used margin:-1em; is to push it under the drop down menu in the form.
My question is: does anybody know if this will have adverse affects on
accessibility or if there are any other weird problems with using this
technique?
In my copy of Firefox, your legend will be 12px in size (minimum
font-size set, us older people really do like that little preference in
the browser ;-))
visibilty:hidden or text-indent:-1px !important are some options.
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, select, and option attributes.
On 6 Nov 2005, at 10:54 am, ivanovitch wrote: Apologies if this has been discussed before, but is it my bad coding, or does Safari (v2.02, latest build) not honour any select styles? Further, is there a way to dictate how option can display styled font attributes across all CSS-compliant browsers? My aim is to make the drop-down in the same style as the rest of the page, but I'm having limited success. Firefox and IE have no problems, on WinXP and OS X (though IE on OS X does odd things when options are selected). Styling form widgets across browsers is notoriously difficult: http://www.456bereastreet.com/archive/200410/ styling_even_more_form_controls/ (and from a usability perspective, not always the recommended option) And no, Safari doesn't allow styling of the select and option, the same goes for Camino and iCab. Opera has a user option to disable author styling of form widgets (something I really like...). 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] Is position:absolute legal in a floated div? relates to a Footer problem in NS7
On 25 Oct 2005, at 11:11 am, Ben Wrighton - StraightForward wrote: After some testing I isolated the float: right; ( to make content 1st in source) and display: inline (which is in there for IE 's double margin bug and will be placed in a IE specific stylesheet in due course) styles as causing the issue. Float: right is the main culprit. Which leads to the topic of this post. 'Is position:absolute legal (or advisable) in a floated div?' Yes, it is completely valid to have an absolute positioned element within a floated block that acts as a containing block. Some older browsers have problems with this, like Netscape 7. You'd have to add an additional wrapper inside your floated block to please those old boys. Like this div style=float:right div style=position: relative p style=position:absolute 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] Set min-width using DOM
On 22 Oct 2005, at 2:53 pm, Lea de Groot wrote:
On Sat, 22 Oct 2005 00:53:51 -0400, Christian Montoya wrote:
width:740px;
expression( fluid and max-width stuff )
Logically, I would expect this to work.
Set the width to 740, then reset it with the expression.
If the expression is inoperative then voila, its set to 740
Yes, that is the solution I've been using for a while, and seems to
work fine.
selector {
width:740px;
width:expression(...);
}
(all dumped inside of a conditional comment, of course).
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] BR tag causes odd behaviour ??
On 17 Oct 2005, at 3:24 pm, Michael Kear wrote:
Can anyone see why the br / is causing the content to drop down
below the
adjacent floated div in the page
http://afterlifelink.com.au/charges/index.cfm?
Because that is what you tell it to do. At the bottom of
http://afterlifelink.com.au/css/formstyles.css
br{
clear : left;
}
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] Counters support?
On 13 Oct 2005, at 8:34 pm, Joshua Street wrote: I discovered a page today that's all about counters and printing things here: http://developer.mozilla.org/en/docs/CSS:Getting_Started:Media#Action: _Printing_a_document I didn't think Firefox supported counters, though... I'd read that Opera did (but later checked that and apparently it's partial/incorrectly implemented - see http://nanobox.chipx86.com/browser_support_css.php#support- css2propsbasic-content ). Does anyone know if Firefox does/doesn't support this, and, if it doesn't yet, is it on the list for Deer Park? Firefox 1.5beta (aka DeerPark) does indeed support counters according to the (current) CSS 2.1 draft. Opera 8.5 and (I think) 8.02 supports that syntax as well. And iCab 3.0. Check bug 3247 which implements it in Gecko https://bugzilla.mozilla.org/show_bug.cgi?id=3247 There was a recent article on ALA where the subject was mentioned more in detail in the comments. http://alistapart.com/articles/multicolumnlists 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 FOUC was site check: liquid.rdpdesign.com
On 12 Oct 2005, at 11:58 am, Steve Ferguson wrote: It does appear that you've killed the Safari FOUC. You should document this as appears to be somewhat of a mystery. I'll second this. I haven't followed the discussion, so it is hard to check for a 'before' and 'after'. 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 FOUC was site check: liquid.rdpdesign.com
On 12 Oct 2005, at 3:52 pm, Christian Montoya wrote: Where would I document this? Blog ? Own website ? You could start here as well, or add an item to the CSS-D Wiki: http://css-discuss.incutio.com/?page=FrontPage 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 caption madness
On 11 Oct 2005, at 3:49 pm, Jake Badger wrote: It already has it, but firefox ignores it if the display isn't block, and if it is it's only as wide as the first cell of the table (as I just said). If you set the display value for the caption to 'block', then it is not a 'table-caption' [1] anymore..., and Firefox, Opera, Safari do display it wherever they feel like, still part of the table anonymous block, but they'll attempt to build a tr/td around it according to the rules in 17.2 [2]. Next, if you want to positioning something absolute within the table-block, you'll bump into an old Gecko bug, where a table-element cannot act as a 'nearest positioned ancestor' for the AP element [3]. Plus, a table caption cannot contain block level elements (your h5). [1] default display-value for caption [2] http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes [3] https://bugzilla.mozilla.org/show_bug.cgi?id=63895 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] :after/:before used for layout
On 12 Oct 2005, at 8:48 am, Gunlaug Sørtun wrote: Jan Brasna wrote: :after generated content cannot receive some CSS properties, including 'position', 'float', list properties, and table properties. That's CSS2. Can't find that line in CSS2.1. All those properties are perfectly fine in CSS 2.1. Unfortunately, those are not yet supported in Gecko browsers https://bugzilla.mozilla.org/show_bug.cgi?id=238072 [...] Firefox won't even react to 'margin', as exemplified by W3C (CSS21), while Opera, Safari, and even iCab, are doing fine with simple 'margin' and absolute positioning. Only Opera seems to be able to handle 'positioned :hover:after'. ?? margin seems to work perfectly fine here. Both on Firefox 1.6a1 nightly trunk build and Firefox 1.5beta 2 http:dev.l-c-n.com/_temp/after.php (the word blah in a grey box after each paragraph, and the word 'the End' as body:after) 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] :after/:before used for layout
On 12 Oct 2005, at 1:00 pm, Gunlaug Sørtun wrote: Philippe Wittenbergh wrote: ?? margin seems to work perfectly fine here. Both on Firefox 1.6a1 nightly trunk build and Firefox 1.5beta 2 http:dev.l-c-n.com/_temp/after.php (the word blah in a grey box after each paragraph, and the word 'the End' as body:after) Working at my end too - once I got my gray cells cranked up. - FF need 'display: block' since it doesn't get 'block' through 'AP'. It works with inline elements as well :-); but vertical margins won't affect the flow. Now, how do one add an empty 'alt-attr' to an image introduced as 'content'. The reason for asking is that Opera show image when images are off and during slow loading, and that's not quite good enough. I don't think it is possible with the current CSS 2.1 syntax. IIRC, there has been some discussion about this on www-style, without any conclusion so far. More like a 'feature request'. Probably something for CSS 3. 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] Jello flexible layout
On 5 Oct 2005, at 10:19 pm, Tom Livingston wrote: However, I managed to get the designer to go another direction with reguards to full height. But full height using Jello Mold is tricky because one of the key structural elements must have a height of 0 within a Holly Hack for IEWin. Traditionally, the hack is used with height:1% (for hasLayout I believe) but anything other than 0 breaks this layout in IEWIN. What Jello Mold need is 'hasLayout' [1] in order to paint those containers correctly in IE. Hence the use of the 'holly hack', which is one the methods to trigger hasLayout. There are other methods though: you could try 'zoom:1', or 'display:inline-block'. Then use and additional container/wrapper to force the height. [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] Flexible Font sizes in tables in ie
On 5 Oct 2005, at 12:50 pm, Kara O'Halloran - Eduka wrote:
Either way I still have the problem of the table cell text either
appearing too large in ie, or too small in ff.
Without resorting to setting text size in pixels in my table, I can't
find any other way to prevent this from happening, I thought perhaps
there might be a hack out there that will pass 0.8em to ie, but not to
firefox?
The problem is the table element in IE that doesn't correctly inherits
the font-size.
What works for me:
body {font-size: 100%} /* or whatever you want, but in percentages */
table {font-size:1em;} /* makes sure the font-size is inherited in IE,
this has to be explicitly 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] Site Review: www.47words.com
On 3 Oct 2005, at 5:47 pm, Gunlaug Sørtun wrote:
I do have one question that just came up while I was chatting with a
friend: Does the hreflang attribute on links do anything, really,
or is it just a cosmetic thing that no browser does anything with?
(I'm using it on links to materials in Mandarin/Malay to indicate
that the content of those sites/pages is in a language other than
English.)
Not updated for the latest browser-versions, but...
http://www.w3.org/International/tests/results/link-element
That list is -unfortunately maybe- quite up to to date. One could add
iCab 3.0 which has a similar 'navigation' bar as Opera and Mozilla to
the list that do something in the UI with some of the link attributes.
The hreflang attribute isn't used by any browser, I think. You can
style it, though, via css2 attribute selectors. Something like this:
a[hreflang]::after {
content: [attr(hreflang)];
font-style:italic;
color:#6c767f
}
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] UTF and IE/Mac - extra character?
On 20 Sep 2005, at 7:32 am, Nick Gleitzman wrote:
I've just built a couple of pages using UTF encoding, rather than
iso-8859-1, and all is as expected, except that in IE/Mac, if you View
Source, there's a single character ('?') as the very first character
of the file - and it renders. Thought at first it might be a localhost
thing, but it happens with the online version as well... This
character is not evident when Viewing Source with any other browser -
or in the HTML file.
HTML is written with BBEdit; I've set prefs to save files as UTF-8
(tried with and without BOM - makes no difference).
First thing I thought when reading your message: BOM. And indeed, it is
there.
I remember, when I still used BBEdit @version 7, I had a hard time
getting rid of it. I think you have to set it first in the application
prefs, save without BOM, before opening any document.
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
**
