RE: [WSG] Unstyling named anchors
> From: Thierry Koblentz > Martin J. Lambert wrote: > > Actually, when using XHTML Strict, "name" is not a valid attribute for > > anchors. You can use the "id" attribute to get the same jump-to-that- > > section-of-the-page behaviour, but this will work with *any* element, > > not just anchors. Since you don't want the appearance of a link on the > > page, I suggest eliminating the anchor altogether and linking to the > > id of whatever element is already there in the markup. > > I'm not sure about that, I think it is better to use both attributes and may > be even "more" to prevent a IE bug related to tabbing navigation. > http://www.motive.co.nz/glossary/anchor.php > http://www.juicystudio.com/article/ie-keyboard-navigation.php I don't see anything in those links that necessitates the use of "name"; the problems seem to be related to the element having 'layout', not which attributes it uses. But if I'm wrong, or if name is required for some other reason, then it's perfectly valid to use it in (X)HTML Transitional, just not Strict. -- Martin Lambert [EMAIL PROTECTED] ** 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] Unstyling named anchors
> From: Paul Noone > > When using XHTML strict named anchors need to surround some link text, yes? > > I'd tinkered with a[name]:hover but I'm loathe to create a style for this. I > don't think hiding them is th eoption either. Actually, when using XHTML Strict, "name" is not a valid attribute for anchors. You can use the "id" attribute to get the same jump-to-that- section-of-the-page behaviour, but this will work with *any* element, not just anchors. Since you don't want the appearance of a link on the page, I suggest eliminating the anchor altogether and linking to the id of whatever element is already there in the markup. -- Martin Lambert [EMAIL PROTECTED] ** 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] Style PRE with word wrap?
> From: Ben
>
> After some testing, I think it's best to stick to using for
> blocks of code. won't preserve whitespace, so your code's
> not going to have any indenting unless you use a lot of non-breaking
> spaces which will inflate the size of your file and not to mention
> a real be a pain in the butt to add.
How about using the element (since it IS code), and using
the following styles:
code {
display: block;
white-space: pre;
}
In my very quick test just now it seems to work in Firefox and IE,
so I'd assume it works pretty much anywhere. This gets you the best
of both worlds - the semantics of and the presentation of
.
--
Martin Lambert
[EMAIL PROTECTED]
**
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] you've been framed - Pt3
designer wrote:
> I've taken your code and added a menu to the top of it, and it works
> after a fashion. It doesn't work in IE5.5 and I don't know what to do
> with it, esp as I don't fully understand what the IE expression is
> doing.
>
> http://www.treyarnon.fsworld.co.uk/kernow/propertydetails/200kmax.html
Odd, because I thought I checked it in IE5.5 before I sent that
message last week; but apparently not, since it appears that it
isn't recognizing the documentElement.
To make it work in IE5.5 and 6, change the expression to this:
top: expression((document.documentElement.scrollTop ?
document.documentElement.scrollTop : document.body.scrollTop) +
Math.random()*0);
IE6 in standards mode will use the documentElement, while 5.5
(as well as 6 in quirks mode) will use document.body.
[What the expression is doing, essentially, is substituting a
JavaScript calculation in place of a static value in the CSS.
It looks at the current value of the scrollTop attribute for
either the documentElement or the body, and uses that as the
top value for the absolutely positioned menu. As the page
scrolls, this value will change and thus the position of the
menu will change to match it. Due to a bug in how expressions
are handled, however, it does not update on the fly like it
should; somebody realized that by forcing it to calculate a
new random number every time the page is scrolled, they could
get it to update the value each time. Hence the Math.random
part.]
> The 'house of the month' page just goes barmy at low res (640
> by 480) and indeed, on the other pages, the div with the tabular data
> sort of slips under the menu div! I've overcome this by putting a
> 50px pad at the top of the data div, but I feel rather like I'm
> wandering about in the dark, not really in control, and certainly not
> yet producing anything worth having!
Looks like the problem for most pages at 640x480 comes from the
menu contents wrapping, so the menu gets taller and starts
covering content. Since you're displaying the list items inline,
if you add:
#menu ul { white-space: nowrap; }
to menu.css, it should prevent that from happening. The menu
will scroll off the right side of the screen instead, but that's
pretty inevitable at such a tiny screen size.
The House of the Month page is a different matter however. The
flash objects on that page are completely obscuring your menu.
Flash will apparently be drawn on top of any HTML elements with
which it intersects on the screen, regardless of source order,
z-index or anything else. To address this, you can position the
flash so it won't intersect with the menu. Adding
padding-top: 50px
to your #layoutgrid td rule will allow the menu to be seen
when the page loads, but then it will still get covered when
they scroll. Since this will apply to a (hopefully) very small
percentage of users, you might be able to live with it like
that. Alternatively, you could remove the fixed/absolute
positioning on that page only, so the menu will scroll up
with the page.
Good luck,
Martin Lambert
[EMAIL PROTECTED]
**
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] you've been framed! - Pt2 : overflow
designer wrote: > So I've done some fiddling with overflow : auto, and failed. > > OK, maybe I'm missing a trick here (do please tell me!) but if not, > it looks as though this solution isn't one, after all. I've never had a lot of success with that overflow idea either. The other way to go at it, though, is to use position:fixed on the menu, and let the rest of the page scroll normally. IE can be made to emulate fixed positioning through several different means. I've taken your source and modified it using IE's expressions to get what I think you're looking for: http://homepage.mac.com/martinlambert/test/kernow.html The one problem I can see is that IE users with Javascript turned off will have the menu scroll with the rest of the page. Up to you whether or not that's a deal breaker... -- Martin Lambert [EMAIL PROTECTED] ** 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] XML Declaration
> Sigurd Magnusson wrote: > >> Is there any situation where IE6 renders in standard compliance mode >> with the preamble? >> Juergen Auer responded: > > If IE6 finds an Xml-Declaration, he switchs in BackCompat. > If my understanding is correct, then this should be phrased somewhat differently. If IE6 sees *anything* before the DOCTYPE, then it switches to quirks mode. It does not look for the XML prolog specifically, and you'll get the same effect by placing a comment there or any other text. (Of course, anything other than the prolog would be invalid, but that's a separate matter.) -- Martin Lambert [EMAIL PROTECTED] ** 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] you've been framed!
Bob McClelland wrote: >> As far as I'm concerned, when you have a great long scrolling list >> (for example) and you want (need) to keep the nav stuff stationary, >> frames represent the ONLY way to do it. Vaska.WSG responded: > > > It can also be done using Microsoft's proprietary expressions, while feeding position:fixed to all other browsers: http://www.mantasoft.co.uk/articles/dynamic-expressions.php As for browsers which don't support frames, you'll probably have the most trouble with handhelds, cellphones and text browsers (which you've already discounted). Any modern desktop browser will handle them just fine. That doesn't make them the only option, however... -- Martin Lambert [EMAIL PROTECTED] ** 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] centering floats?
Alan Trick wrote: > Centering the containiner is meaningless though if it doesn't have a > fixed width (that's smaller than it's container), and if it does have > a fixed width, than it ruins the whole point of the thing, to allow > the boxes to flow depending on the size of the container. > > David Laakso wrote: >> You could center the container holding the floats using margin auto; >> however, you would not be able to center the floats within that >> container-- it's pick your poison, either float them left, or float >> them right. You could let JavaScript handle it. As soon as the page loads, check where the rightmost float falls and adjust the width of the (centered) container accordingly. If the user doesn't have JavaScript, they'll still get the left-floated version that you're settling for anyway. Martin Lambert [EMAIL PROTECTED] ** 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] scribbles
designer wrote: > > http://www.betasite.fsnet.co.uk/comment/scribblings.html > On this page, you write: "Of course you can use javascript to open a new window (onClick), but that isn't the point, is it?" I think that's exactly the point, however. My understanding is that the W3C did not remove the target attribute because opening windows is "evil", but because it's not structural. They've relegated this *behavior* to the behavior layer (JavaScript) instead of the structural layer ([X]HTML). Granted, not everyone can use JavaScript or has it turned on, so they simply won't have this behavior triggered, just like any other scripting they may encounter on the web. If it's absolutely vital that the link opens in a new window for every user (which of course still only means those users whose browsers understand and act upon the target attribute), you can certainly use the transitional DTDs where it is still perfectly valid. One person I work with writes XHTML that is entirely strict-compliant except for target, and uses the transitional DTD on the few pages that need it. -- Martin Lambert [EMAIL PROTECTED] ** 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] doctypes, quirks/standards mode and positioning
[EMAIL PROTECTED] wrote: > Thanks for the clarification. However, I still don't understand WHY a > page requires a doctype declaration (in my case HTML 4.0 > transitional) just to make a font-size style cascade from body > through to td. I believe it's simply that quirks mode follows older browser behavior, where td's did not inherit styles from body, or anything else outside of their table. In standards mode, they do (correctly) inherit the styles. Look at your pages in Win/IE 5 or anything older to see it, regardless of doctype. This was also why, in the bad old days, every single table cell needed its own tag - there was no way to set the style outside the table and have it be inherited. -- Martin Lambert [EMAIL PROTECTED] ** 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] applying style to the 3rd column of a table?
Philippe Wittenbergh wrote: > > On a side note, if a table contains more than 3 columns, then the > syntax td+td+td will give a background colour to more than one column. > You'd need to add td+td+td+td to override the previous one. Or alternatively, change it to td:first-child+td+td -- Martin Lambert [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] Changing the DOCTYPE messes up the page
Justin French wrote: > > Well, you didn't tell us that the watermark was generated content from > a JS file, and I didn't look. Even though your source validates, you > must understand that the (X)HTML that the javascript program writes > internally doesn't appear in the source that W3C validates. > > In short, your problems are here. The HTML that the JS writes must be > valid for the DOCTYPE you're using (although it's very hard to check > this, if not impossible), and the CSS you use to style the watermark > inline must also be valid. Actually, it shouldn't be hard to check at all: view source of the rendered page, save to a file, and upload the file to the validator. Fix errors. Repeat until it passes. -- Martin Lambert [EMAIL PROTECTED] * 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] Oh, the humanity!
Rev. Bob 'Bob' Crispen wrote: > > > This isn't a simple "brochure-ware" site of static pages. > > Why not? I agree with most of what you wrote, but just wanted to address this one point. I used to work for CDNOW before it went under, and can tell you why it isn't a simple site of static pages - there's WAY too much music out there, changing MUCH too quickly, to ever hope to keep up with it manually. That said, there's absolutely no reason why it couldn't be a simple site of database-driven *templates*, each of which adheres to web standards and is accessible to all visitors. I've done it myself, on a site that actually licensed much of AllMusic's content. -- Martin Lambert [EMAIL PROTECTED] * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
