Re: [WSG] All is not well...
Done it. Georg? margin-right:-6px; did not work on the right side of the container but 'margin-LEFT: -6px' did! Why do negative margins shift things around in a better way than positive ones? ** 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] All is not well...
Done it. Georg? margin-right:-6px; did not work on the right side of the container but 'margin-LEFT: -6px' did! Why do negative margins shift things around in a better way than positive ones? Because negative margins pull, while positive margins push. And everyone knows it's easier to pull than to push :) -- -- C Montoya rdpdesign.com ... cssliquid.com ... montoya.rdpdesign.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] All is not well...
Adam Morris wrote: Done it. Georg? margin-right:-6px; did not work on the right side of the container but 'margin-LEFT: -6px' did! My fault - sorry. Yes, it should be a negative margin-left on the right container :-) Why do negative margins shift things around in a better way than positive ones? In your case: the negative margin is pulling in the backside edge of the floating container - the container becomes so many pixels narrower when the browser is calculating its space in relation to other elements. The actual, and visual, width stays the same though, so the containers starts to cover each other visually. That's one way to make the gap disappear. Note that this is a solution that'll only work well on floats. Floats can be positioned and manipulated by frontside and backside margins in many ways. Create some tests so you know how to control them. It may come handy. Example: http://www.gunlaug.no/contents/wd_chaos_04.html More extreme examples - with IE/win fixes: http://www.gunlaug.no/contents/wd_demo_float_01.html http://www.gunlaug.no/contents/wd_demo_float_02.html http://www.gunlaug.no/contents/wd_demo_float_03.html ...links to more float-info in the side-column(s). regards Georg -- http://www.gunlaug.no ** 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 11/17/05, Patrick H. Lauke [EMAIL PROTECTED] wrote: Linking back to my philosophical question at the beginning: is web development a subset of software development, or is it - for lack of a better term - the development of an experience. A related point from that: should web applications (functional, intranet-type apps) still have their own feel or integrate seamlessly (from a visual standpoint) with the OS? I think part of the problem here is that, despite any wishes we might have to the contrary, web browsers don't consistently integrate with the look and feel of the OS. Internet Explorer uses Windows' form controls, yes, and Safari uses the Mac OS' controls, but (for example) Gecko-based browsers have their own set which, while reminiscent of older versions of Windows, really isn't native to anything. And despite much progress on the OS-integration front, Firefox still doesn't really feel like a native application on any platform. Opera occasionally has the same problem; here on Linux, even though it uses the Qt toolkit (or did last time I checked), it doesn't use the default Qt widgets for form controls. And even if there were perfect consistency of browser form widgets with OS widgets, we would still be stuck with a fundamental problem: web applications, by definition, run in web pages, and no OS in widespread use has an application paradigm which matches that of web pages. So despite consistency of the widgets used for certain parts of web applications with widgets used in certain parts of traditional applications, we would still be working in a fundamentally different medium. And I think that web users, on the whole, have come to understand and expect that things on the web work differently from the other applications they use, so striving to be as much like the OS as possible would be a futile and counterproductive task. Which, I guess, leads us to the latter of your two options; as I see it, a web application ought to have a simple, intuitable interface (or experience) which is consistent within that application, because ultimately that is all the control the web application's designer will ever have. This does not mean that conflicts with widespread OS interface conventions should not be avoided when possible, but it does mean that consistency with the OS interface should not be valued more highly than consistency, simplicity or intuitability within the web application. -- May the forces of evil become confused on the way to your house. -- George Carlin ** 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 11/18/05 2:16 AM James Bennett [EMAIL PROTECTED] sent this out: I think part of the problem here is that Great read. Thanks. You have many valid thoughts, and you express them well. :-) Rick Faaberg ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Inline link padding in IE6
I've come accross an interesting (and painful) bug in IE6, when you have padding on a link, and a background colour set, and then margin to stop the link shifting, IE fails to draw the background over the padding: http://www.pixelcarnage.com/dump/rn.html I've tried many things, including giving the inline link layout, but that doesn't work either. Any thoughts? -- Rowan Lewis (AKA. The Wolf) ** 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] Inline link padding in IE6
Rowan Lewis wrote:
I've come accross an interesting (and painful) bug in IE6, when you
have padding on a link, and a background colour set, and then margin
to stop the link shifting, IE fails to draw the background over the
padding:
http://www.pixelcarnage.com/dump/rn.html
I've tried many things, including giving the inline link layout, but
that doesn't work either.
It is difficult to give a link layout, but 'zoom: 100%' will work. Need
to zero out that padding on top/bottom.
a:hover {
background : #dfdfdf;
margin : 0 -0.25em;
padding :0 0.25em;
zoom: 100%;
}
...complete and working.
Georg
--
http://www.gunlaug.no
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[WSG] ACCESS + KEY still = ACCESSKEY
With apologies for cross posting. Dear Friends, For the many that know me, you will know that a post to any of the lists I subscribe to on the topic of ACCESSKEY will automatically receive a response from me. I think by now my position is abundantly clear on this topic. When I first heard that XHTML 2 was deprecating ACCESSKEY in favor of the ACCESS element and the ROLE attribute, my initial reaction was, Finally, they will get this right and a predictable, useful, stable means will finally emerge to provide keyboard navigation to those that can truly benefit from it. For while I have continually decried the mess and potential for harm that ACCESSKEY presented, I have always supported and advocated for a better way, and we publicly applauded the W3C for getting it too (Aug. 14, 2004 - http://www.wats.ca/articles/thefutureofaccesskeys/66). Along the way however, the ACCESS element has been shackled with the KEY attribute, allowing the possibility for the content author to dictate a specific key binding to one or more of the access points, in effect, I believe, replicating and perpetuating many of the most serious issues with ACCESSKEY: keystroke conflicts, little or no conflict resolution, internationalization issues, lack of an existing or persistent standard, etc. And so I have asked the Editors of the XHTML 2 Draft Recommendation to remove the KEY attribute from the specification. The full text of my request is published on the WATS.ca website: http://www.wats.ca/articles/xhtmlroleaccessmodulestillflawed/80 I ask that you take the five minutes required to review my request, and if you believe, as I do, that the KEY attribute has no place in XHTML 2, then I urge you to say so to the Draft Editors at [EMAIL PROTECTED] Remember, The World Wide Web Consortium (W3C) is an international consortium where Member organizations, a full-time staff, AND THE PUBLIC work together to develop Web standards. (http://www.w3.org/Consortium/) Thank you. JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** 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] Inline link padding in IE6
Thanks George, for helping me give it layout.
But the top/bottom padding was an important part of the desired effect :/
Any idea how to do it?
On 11/18/05, Gunlaug Sørtun [EMAIL PROTECTED] wrote:
Rowan Lewis wrote:
I've come accross an interesting (and painful) bug in IE6, when you
have padding on a link, and a background colour set, and then margin
to stop the link shifting, IE fails to draw the background over the
padding:
http://www.pixelcarnage.com/dump/rn.html
I've tried many things, including giving the inline link layout, but
that doesn't work either.
It is difficult to give a link layout, but 'zoom: 100%' will work. Need
to zero out that padding on top/bottom.
a:hover {
background : #dfdfdf;
margin : 0 -0.25em;
padding :0 0.25em;
zoom: 100%;
}
...complete and working.
Georg
--
http://www.gunlaug.no
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
--
Rowan Lewis (AKA. The Wolf)
**
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] Inline link padding in IE6
Gunlaug Sørtun wrote:
It is difficult to give a link layout, but 'zoom: 100%' will work.
Question: Which CSS standard defines the zoom property?
I don't see it in CSS2, nor in the CSS2.1 working draft. I
suspect it's a Microsoft invention and its use will invalidate
the CSS.
You could use { display: inline-block } instead. At least that's
defined in the CSS2.1 working draft.
Regards
--
Bert Doorn, Better Web Design
http://www.betterwebdesign.com.au/
Fast-loading, user-friendly websites
**
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
Rick Faaberg On 11/18/05 2:16 AM James Bennett [EMAIL PROTECTED] sent this out: I think part of the problem here is that You have many valid thoughts, and you express them well. :-) So what, most of the ramblings of Geoff and I posted were invalid and badly expressed? ;) Nah, just pulling your leg. Glad to see more people jumping in on the conversation. P Patrick H. Lauke Web Editor / University of Salford http://www.salford.ac.uk Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ** 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] Inline link padding in IE6
Rowan Lewis wrote: Thanks George, for helping me give it layout. But the top/bottom padding was an important part of the desired effect :/ Any idea how to do it? Well, first you must set padding on the link - without hover - to make it height-stable. Then you can play around with some line-height adjustments for IE6 so it won't break the entire text-line. Even some vertical-align may help. Plenty of options, but even more IE-bugs I'm afraid. Then you should wrap the entire IE-garbage in a separate stylesheet and keep it away from the validator and those who don't think IE6 should get what it can make any use of, because it isn't standard. Georg -- http://www.gunlaug.no ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Re: All is not well...
Thanks for the links, Gunlaug. A great css step forward for me, this one! Adam On 11/18/05, Gunlaug Sørtun [EMAIL PROTECTED] wrote: Adam Morris wrote: Done it. Georg? margin-right:-6px; did not work on the right side of the container but 'margin-LEFT: -6px' did! My fault - sorry. Yes, it should be a negative margin-left on the right container :-) Why do negative margins shift things around in a better way than positive ones? In your case: the negative margin is pulling in the backside edge of the floating container - the container becomes so many pixels narrower when the browser is calculating its space in relation to other elements. The actual, and visual, width stays the same though, so the containers starts to cover each other visually. That's one way to make the gap disappear. Note that this is a solution that'll only work well on floats. Floats can be positioned and manipulated by frontside and backside margins in many ways. Create some tests so you know how to control them. It may come handy. Example: http://www.gunlaug.no/contents/wd_chaos_04.html More extreme examples - with IE/win fixes: http://www.gunlaug.no/contents/wd_demo_float_01.html http://www.gunlaug.no/contents/wd_demo_float_02.html http://www.gunlaug.no/contents/wd_demo_float_03.html ...links to more float-info in the side-column(s). regards Georg -- http://www.gunlaug.no ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 11/18/05, Patrick Lauke [EMAIL PROTECTED] wrote: Rick Faaberg You have many valid thoughts, and you express them well. :-)So what, most of the ramblings of Geoff and I posted were invalidand badly expressed? ;) Yes, please validate your next ramble with one of the W3C's online tools please :pI must admit I've been an avid follower of this thread aswell, and if it weren't for you jumping in with my exact same thoughts Patrick, Id've joined in long ago :) In all seriousness, I see this whole discussion as a Good Thing, and as long as it doesn't sink to the name calling level it should continue for as long as you guys (and anyone else who cares to jump in) have something pertinent to add. -- Lindsay Evanshttp://lindsayevans.com/
Re: [WSG] Accessibility: Default placeholders
Herrod, Lisa wrote: for the record, I'm still following the thread. this isn't even close to finished. I think it's best if I take a time out and write a thorough article. If it is a topic worthy of more discussion, I think that is the best way to serve that purpose. --- Geoff Deering ** 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
James Bennett wrote: On 11/17/05, Patrick H. Lauke [EMAIL PROTECTED] wrote: Linking back to my philosophical question at the beginning: is web development a subset of software development, or is it - for lack of a better term - the development of an experience. A related point from that: should web applications (functional, intranet-type apps) still have their own feel or integrate seamlessly (from a visual standpoint) with the OS? I think part of the problem here is that, despite any wishes we might have to the contrary, web browsers don't consistently integrate with the look and feel of the OS. Internet Explorer uses Windows' form controls, yes, and Safari uses the Mac OS' controls, but (for example) Gecko-based browsers have their own set which, while reminiscent of older versions of Windows, really isn't native to anything. And despite much progress on the OS-integration front, Firefox still doesn't really feel like a native application on any platform. Opera occasionally has the same problem; here on Linux, even though it uses the Qt toolkit (or did last time I checked), it doesn't use the default Qt widgets for form controls. That's an absolutely spot on observation, and it does impact the user experience. Some applications style the look and feel of various system resources by compiling their own resource design into their own application, rather than purely passing it to the OS. And even if there were perfect consistency of browser form widgets with OS widgets, we would still be stuck with a fundamental problem: web applications, by definition, run in web pages, and no OS in widespread use has an application paradigm which matches that of web pages. So despite consistency of the widgets used for certain parts of web applications with widgets used in certain parts of traditional applications, we would still be working in a fundamentally different medium. And I think that web users, on the whole, have come to understand and expect that things on the web work differently from the other applications they use, so striving to be as much like the OS as possible would be a futile and counterproductive task. But the web developer still has to keep in mind that their application is being rendered on multiple devices for which they do not know how each are configured. Also, there are units of measure and design implementations that these device will be able to translate directly to suit the display of these devices, and there are others that will clash. If nothing else, WCAG is a very good basic check list to help the designer avoid many pitfalls. It can only help to be mindful of these things while designing. Which, I guess, leads us to the latter of your two options; as I see it, a web application ought to have a simple, intuitable interface (or experience) which is consistent within that application, because ultimately that is all the control the web application's designer will ever have. This does not mean that conflicts with widespread OS interface conventions should not be avoided when possible, but it does mean that consistency with the OS interface should not be valued more highly than consistency, simplicity or intuitability within the web application. Yes. This is probably so important it is an issue the both UAAG and WaSP should drive home to user agent developers. - Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Firefox :hover font-weight: bold
Does anyone have any experience with a bug in Firefox when using a:hover
{font-weight:bold;}?
When the cursor moves over the link, other elements on the page shift or
even flicker over other elements. Basically, the page is in chaos on :hover.
Fixes, suggestions, guesses appreciated!
Regards,
Stuart
**
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 :hover font-weight: bold
its not to do with a bold font taking up more space and shifting other
elements?
Stuart Sherwood wrote:
Does anyone have any experience with a bug in Firefox when using
a:hover {font-weight:bold;}?
When the cursor moves over the link, other elements on the page shift
or even flicker over other elements. Basically, the page is in chaos
on :hover.
Fixes, suggestions, guesses appreciated!
Regards,
Stuart
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
.
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Firefox :hover font-weight: bold
also are you certain you have closed all your a tag's?
Charlie
http://www.bartlettdesign.co.uk
On 11/19/05, James Gollan [EMAIL PROTECTED] wrote:
its not to do with a bold font taking up more space and shifting otherelements?Stuart Sherwood wrote:
Does anyone have any experience with a bug in Firefox when using a:hover {font-weight:bold;}? When the cursor moves over the link, other elements on the page shift or even flicker over other elements. Basically, the page is in chaos
on :hover. Fixes, suggestions, guesses appreciated! Regards, Stuart ** The discussion list for
http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help
** .**The discussion list for
http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor some hints on posting to the list getting help**
Re: [WSG] Firefox :hover font-weight: bold
its not to do with a bold font taking up more space and shifting other elements? also are you certain you have closed all your a tag's? No, I wish it was this simple. I'm talking about elements that are located on the other side of the page flashing above the link with the hover. I'll get a test page up soon. Cheers, Stuart ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] MSIE standalone from quirksmode and conditional comments
Hi all, I'm using the standalone MSIE 5.01 and 5.5 from www.quirksmode.org to tweak a design for IE5 and 5.5. This went perfectly fine, the site looks great. However I have one question: Is it just me or don't these versions pick up conditional comments for various older IE versions? For example: !--[if lt IE 5.5] link href=/stylesheets/theme/msie5.css media=screen rel=Stylesheet type=text/css / ![endif]-- This doesn't get picked up at all. I just want to make sure I'm not doing something wrong. I need a correct conditional comment that's picked up by IE 5.5 and 5.0. I'm sure there must be people on this list who worked with these sandboxed MSIE versions so I thought I'd ask. Thanks in advance! Marco ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
