Re: [WSG] XHTML Strict alternative to ol start=11
Placing his list in a dl or table and manually numbering them works, but what about when a new item needs to be added to the list somewhere in the middle? I'm assuming a system like this is dynamically handled back-end, so removing this problem. I'm not sure what the rational for dropping the start= from ol was, and at first glance it seems an odd thing to do. Like others have mention, I can see cases where it would be useful - a results list with 1,000 entry, for example, displaying 50 at a time. But you've got to think in terms of a page - the first list item in a page is still the first list item, regardless of where it comes in the multi-page 1,000 results. --- Vivabit Ltd., London http://vivabit.co.uk @media 2005 http://www.atmedia2005.co.uk ** 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 Strict alternative to ol start=11
In this instance, all the padding, margin, border, etc. were initially
set
to zero so that shouldn't be the cause here. In the end I couldn't
find the
cause of this IE issue, so I've gone with a table. I can always have
it
changed if I discover the cause and a fix.
Hi Ian. I don't know if I've missed something, but in your original
example:
dldt99./dtdda href=Article title/a/dd
dt100./dtdda href=Article title/a - span
class=newNEW/span/dd
/dl
and:
dt { float:left; }
dd { margin:4px 8px; }
The problem is in your margin for the dd's and nudging them out of line
with the dt's. Try margin: 0 8px 4px 8px; instead, or applying some
kind of combination of margins to the dt's (or first dt).
---
Vivabit Ltd., London
http://vivabit.co.uk
@media 2005
http://www.atmedia2005.co.uk
- Original Message -
From: Ian Fenn [EMAIL PROTECTED]
To: wsg@webstandardsgroup.org
Sent: Tuesday, February 08, 2005 9:51 PM
Subject: RE: [WSG] XHTML Strict alternative to ol start=11
Patrick wrote:
doesn't work all the time, but as a general rule: when you have this
type of inconsistencies, try and be very specific with regards to
all
margins and paddings. Otherwise, you're leaving the ones you don't
specify up to the rendering engine's default, which may well vary
from
browser to browser.
In this instance, all the padding, margin, border, etc. were initially
set
to zero so that shouldn't be the cause here. In the end I couldn't
find the
cause of this IE issue, so I've gone with a table. I can always have
it
changed if I discover the cause and a fix.
Thanks for your help everyone.
All the best,
--
Ian Fenn
Chopstix Media
http://www.chopstixmedia.com/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] XHTML Strict alternative to ol start=11
See, I'd say a table or a definition list. I think I'm one of the very few people who actually supports the loss of the start= attribute. I'd go with Michael, on both points. Table would be fine, but definition list is probably better. And the start attribute is bad because the first item in an ordered list is always, well, the first item! All this talk of writing your own DTD is a bit nuts if you ask me. The standards are in place for a reason. Patrick --- Vivabit Ltd., London http://vivabit.co.uk @media 2005 http://www.atmedia2005.co.uk ** 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] Drop down menu, JavaScript accessibility
Nope, nothing at all. Just bung it in an IE conditional clause calling a stylesheet containing an HTC behaviour call. IE conditional clause? HTC? *Web Standards* Group? ;) ** 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] London Web Standards Conference
Just thought y'all'd like to know... @media 2005: Web Standards Accessibility is coming... On the 9th and 10th June, well known web designers and accessibility experts including Jeffrey Zeldman, Doug Bowman, Joe Clark and a host of UK pro's will be descending on London to speak about the hottest issues in web design. You can find out more, help to support and register on the shiny new website: http://www.atmedia2005.co.uk Patrick - Patrick Griffiths Wrote a book: XHTML CSS: A Web Standards Approach (New Riders) Started a company: http://vivabit.co.uk Made a web site: http://www.htmldog.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] Embed tag, object and web standards
Currently the best advice is to validate media content pages as HTML v4 transitional. Personally, I think the best approach is still Flash Satay: http://www.alistapart.com/articles/flashsatay/ Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Fixed vs flexible layouts
Fixed vs. Liquid. Excellent! I love these arguments. I'm sure we'll see about 300 replies to this that go way off topic in a general Fixed is better! - NO! Liquid is better style. The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. The WCAG are so vague, often with a get out clause of well, if you can't really achieve that then if you vaguely do this to compensate then that's alright kind of thing. It's not that difficult to argue that something is AA for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Andy Budd For a site to get a AA accessibility rating, you are supposed to use relative units (%, em) rather than fixed units (px). However the WAI guidelines do say that, if you use fixed units, you must make sure that your site is usable. Personal preferences aside, what accessibility problems to people see with fixed width layouts and what are the scale of these problems. Could the same arguments hold true for elastic layouts (layouts based on ems) and do flexible layouts (those based on %) have their own accessibility issues? Is it acceptable for the vast majority of fixed width CSS based sites to claim AA compliance if all other priority 1 and 2 checkpoints are met? * 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] Hacks
The only hack that I think is really necessary is the box model hack. Hacks are over-used, usually to quickly solve a cross-browser problem that can actually be fixed with good, non-hack CSS. This is the goal of web standards after all - one size fits all. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Andy Budd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 30, 2004 11:19 AM Subject: [WSG] Hacks Whenever I trawl lists like css-discuss, I'm always surprised about the amount of hack related discussion there is. People are always talking about the holy hack, the underscore hack or the star hack, about IE7, the high pass filter or the mid pass filter. As somebody who is quite experienced with CSS you'd be forgiven for thinking that I'd know about all these hacks. However about the only hack I use (and have ever actually needed) is Taneks old school box model hack, and even this I use sparingly. So I'm interested to hear what you folks think. Do you hack or are you hack free? If you hack, what methods do you use, why do you use that method, and more importantly, why do you need it in the first place? Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Andy Budd wrote: If you are embedding widths in the HTML this is definitely an issue. However if you are doing it using CSS, these devices should really use 'handheld' stylesheets instead of those intended for 'screen'. Indeed they should. Unfortunately, a lot of mobile browsers (such as PPC IE) apply the screen media type. I doubt that using a flexible layout would be that much better. Take your typical 3 col layout for instance. Reduced down to a mobile phone sized screen you'd have exactly the same issue as described in your first para. i.e. The text in each col would be so squashed up as to be unreadable. For some (maybe most) devices, sure, but some screens (especially those on PDA's and PDA-style phones) are wide enough to accommodate multi-column layouts. It depends what you need to do with your design. 3 columns would certainly be pushing it, but two column or (obviously) single column designs would probably usually work better within a fluid design. Like I say, it comes down to what you're trying to do with the page. Dog Boy Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Andy Budd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 30, 2004 11:53 AM Subject: Re: [WSG] Fixed vs flexible layouts Patrick Griffiths wrote: The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). That's my problem with using ems. You maintain the 'words per line' but risk horizontal scrolling. Yet the horizontal scrolling/small screen issue seems to be the main reason why the WAI advocate using relative units instead of absolute units. Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. If you are embedding widths in the HTML this is definitely an issue. However if you are doing it using CSS, these devices should really use 'handheld' stylesheets instead of those intended for 'screen'. I doubt that using a flexible layout would be that much better. Take your typical 3 col layout for instance. Reduced down to a mobile phone sized screen you'd have exactly the same issue as described in your first para. i.e. The text in each col would be so squashed up as to be unreadable. The WCAG are so vague, often with a get out clause of well, if you can't really achieve that then if you vaguely do this to compensate then that's alright kind of thing. It's not that difficult to argue that something is AA for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Agreed. One of the reasons I posted here was because there are a few WCAG members on the list. I'd be interested to hear their rational behind this guideline. It seems to me that whether you use fixed or flexible layouts there will always be accessibility issues at the extreme ends of screen size. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Geoff Deering wrote: The absolute irony here is that pixels (px) are classified as relative units. I know, I can never get my head around this one either, but it's great news for those of us trying to get good layouts and address accessibility. A pixel is relative because it can be any physical size - it can be one millimetre wide or one inch wide, for example. That's not particularly helpful for a web designer though. It *is* absolute in relation to the screen size, which is kind of a contradiction, but a much more useful way to think about it. I'm quite sure that when the WCAG authors say absolute units they are talking about pixels. If my memory serves me correctly, they more or less say this. Again, it's open to interpretation, but we all know what they're getting at, really. The WAI purists would say an all em site is better, but that is just not realistic in todays world. Sure it's realistic. It's one of many options and some people have opted for ems and successfully built elastic pages. Fido Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Fixed vs flexible layouts
Geoff Deering wrote: I'm quite sure that when the WCAG authors say absolute units they are talking about pixels. If my memory serves me correctly, they more or less say this. Again, it's open to interpretation, but we all know what they're getting at, really. No, that is not correct, WCAG directly references the HTML and CSS specifications and does not have their own differing interruptation of any of the specifications. Okay, well I took a quick look and there is no direct reference to pixels. It is quite clear that the gist is to use ems or percentages however. In http://www.w3.org/TR/WCAG10-CSS-TECHS/#units for example: ...you may position an image to be offset by 3em from the top of its containing element. This is a fixed distance, but is relative to the current font size, so it scales nicely. It works for simple layouts, but I don't think it works for complex layouts across multiple users agents. If it does, can you please show me an example. http://www.csszengarden.com/?cssfile=/063/063.css I don't see what the big deal is. You can just take a pixel-laden layout and replace values with suitable ems values. Why isn't this realistic? Mutley Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Safety experts advise switching browsers
Ubizen has advised computer users to switch to alternative web browsers like Netscape or Mozilla for the moment. Now the question is will anybody switch? Wow. Wouldn't it be great if people did? I think what would be better than individuals switching would be for computer manufacturers to pre-install Mozilla or Opera on PC's. That's the main reason why such a majority of people don't switch - they stick with what's on their system (which is why there's still a sizeable market share using IE 5). Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Mordechai Peller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 9:03 PM Subject: [WSG] Safety experts advise switching browsers This may be good news for standards. http://www.itweek.co.uk/News/1155868 : Ubizen has advised computer users to switch to alternative web browsers like Netscape or Mozilla for the moment. Also at: http://www.ubizen.com/c_about_us/2_public_relations/2004/040611_e.html Now the question is will anybody switch? Note: I have nothing against MS. If there browser was standards compliant and didn't have more holes than Swiss cheese, I would have much to complain about (then again, there's always Windows). * 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] HTML, CSS and Mobiles
I'm attempting to find out what support browsers on mobile devices such as PDA's and phones have for the handheld media type. Has anyone got any of experience of this? I've supplied a bit of background info here: http://www.htmldog.com/ptg/archives/55.php And if anyone with a web-ready PDA or phone could let me know what results they get with this test page... http://www.htmldog.com/test/handheld.html ...I would be eternally grateful. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] CSS vs tables - the untitled posts
From: Jamie Mason Ok, Rimantas, replicate http://seowebsitepromotion.com without tables and without hacks. - Mike Pepper Hi, I don't want to lower the tone, but was that comment a joke or were you serious? Your site is a standard 3 column layout, it's perfectly possible to build that in CSS-P. From what I understand (correct me if I'm wrong), the main point was that there is a footer and two main areas that are of equal height, regardless of the amount of content in either area. This is still possible with floats, but complicates the matter a bit more than your standard CSS column layout. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] CSS vs tables - the untitled posts
I like the design of the site. And it's particularly impressive from someone who's only been at it for 8 months! It can be done in CSS though, and without the need for lots of nested divs or hacks. You basically need to float the two main areas and use the footer to produce the bottom border of the main content area. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Mike Pepper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 28, 2004 5:01 PM Subject: RE: [WSG] CSS vs tables - the untitled posts MessageAnd then the bloody this collapses erratically! I nearly went bald trying to find a resolution to this. I spend a couple of solid days examining options. Had a few CSS techies up for the challenge and we couldn't get it to render properly. I've been with the negative flanking columns but it seemed that one resolution clobbered another aspect. In truth, I should have documented the working procedure but it got to the stage where you have literally dozens of backups (and way to much espresso). I may revisit it again but I've had 3 shots at it with various guys examining it. It's quite possible to achieve the 'cool' style but implementing the other two proved a pig. If I dropped them, I could do it. But that's again surrendering to limitations of pure CSS. However, I am open to options. I'm not a sparkling CSS developer and have been in the game for only 8 months or so. There are far more knowledgeable guys around. I'm just loath to go down the road of nested divs and fudges to get something to work which can be achieved more practicably with a simple framing table. Mike * 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] Good DOM tutorial?
Does anybody know a good DOM tutorial? They seem to be few and far between, but this: http://www.brainjar.com/dhtml/intro/ and then this: http://www.brainjar.com/dhtml/events/ are by far the best DOM tutorials I've found. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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 *
[WSG] Suckerfish Galore!
Thanks very much for the comments on the Suckerfish Dropdowns article. There are now more Suckerfish articles up on HTML Dog that explain how you can mimic :hover, :active, :focus and even :target for some interesting results: http://www.htmldog.com/articles/suckerfish/ I've been putting last minute touches to this last night and this morning (I'm on UK time), but there's quite a lot of stuff in there and my head is now starting to hurt, so if you find any typo's or other errors, please let me know... Cheers Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Tables are bad because...
Who are all of these mad heavy-handed authoritarian web nuts that you're talking about? ;) From what I see there are different ways of putting over a point, each one usually as legitimate as the other and they all usually contribute to a stronger understanding of web standards for those new to the area and for those with more experience. Web designers tend not to be stupid people and if you can put forward an intelligent and logical argument, there's no need to sit on the fence. Being prescriptive is obviously a bad thing, but justified reasoning can be enlightening and inspiring. When I want to learn something, I want to know how to do it the right way and, usually, the best way. I know it's going to take me time to learn it, but I'd rather know what I'm ultimately aiming for rather than going for something that's not quite as good. I think most people would agree that there are *some* individuals who have a very purist and prescriptive approach to standards. Purist is ok, as long as it doesn't affect practicality. Prescriptive isn't ok, but even if an 'extreme' argument can be backed up with sound justification then it can only be a good thing. There is also a lot of theoretical discussion about web standards going on at the moment. For people within the community, I'm sure all this all feels reasonable. We know that we are partaking in a theoretical discussion and that in reality, things are less black and white. However, if you are outside the community, this kind of attitude can feel extremely intimidating. Or, if the full potential of web standards can be conveyed, inspiring. I agree that there is a big difference between the theoretical and the practical, but again, where are these people who put theory before practice? However some individuals can come across as dogmatic and prescriptive. Nobody likes being preached at or being told that their hard work is in vein because they used a table to lay out a form, or have a few minor validation issues. Agreed. Who's saying that though? Most comments I see are along the lines of this would be better if... rather than No you oik! Your work is WORTHLESS CRAP DAMN YOU! I think it does the community and the web standards cause a much greater disservice to stand dogmatically behind a set of beliefs, thus helping to reinforce the stereotypes even more. Don't stifle discussion or knock those who deviate from the party line. I'm all for pushing the standards boundaries, but we also need to accept and talk about the limitations involved. If we don't acknowledge and discuss the limitations as a community, you know that others will. Acknowledge limitations yes, but where there are real demonstratable advantages to be had they should be raved about; shouted from the tree tops rather than beating around the bush. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Tables are bad. Just because. [was APC magazine anti standards article]
As you may have guessed, my post was partly in response to the awful article in APC mag. While I agree that the APC article needs a literary slapping as often as possible, I feel that Mr. Budd's devil's advocacy tries to sit on the fence too much when there's soft grass on one side of it and dirt on the other. You can still maintain objectivity while dismissing anti-web standards comments with a heavier hand if the argument is a logical one. Here's my two pence worth to this whole rhubarb: http://www.htmldog.com/ptg/archives/49.php Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Andy Budd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 14, 2004 9:57 AM Subject: Re: [WSG] APC magazine anti standards article Hey John, As you may have guessed, my post was partly in response to the awful article in APC mag. http://www.andybudd.com/archives/2004/04/ inciting_the_bile_of_the_web_standards_community/ I really didn't want it to become the definitive anti CSS article so thought a more level headed look at the table vs CSS debate was required. Andy Budd * 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 declarations, apos; and IE
This is probably a dumb question, but am I right in assuming that IE will only correctly display an apos; character entity if the XHTML file has an XML declaration? Doesn't appear to, which is a bit odd. #39; is fine though. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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 transitional is a half-way house
I thought XHTML transitional _is_ XML. In what way is XHTML transitional is a less strict data format? It's a transition. It's a half-way house between HTML 4 and XHTML as it is intended (XHTML Strict). No its not. There is no such thing as a half-way house between HTML 4 and XHTML. Sure there is. That's what it's meant to be anyway. What else does 'Transitional' mean? - It's a bridge between what people were used to to something newer. Which is why it's the same as XHTML Strict, just with a generous helping of 'old' elements to ease the transition. XHTML defines a reformulation of HTML 4 as an XML 1.0 application, and three DTDs corresponding to the ones defined by HTML 4 http://www.w3.org/TR/2002/REC-xhtml1-20020801/#abstract The difference between a strict and a transitionl DTD (eg HTML4.01 Strict and HTML4.01 Transitional) is that the strict DTD has depreciated elements and attributes removed.. There you go. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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 transitional is a half-way house
I thought XHTML transitional _is_ XML. In what way is XHTML transitional is a less strict data format? It's a transition. It's a half-way house between HTML 4 and XHTML as it is intended (XHTML Strict). No its not. There is no such thing as a half-way house between HTML 4 and XHTML. Sure there is. That's what it's meant to be anyway. What else does 'Transitional' mean? - It's a bridge between what people were used to to something newer. Which is why it's the same as XHTML Strict, just with a generous helping of 'old' elements to ease the transition. What ever XHTML transitional it is, it is not a bridge or a half-way house between HTML4 and XHTML. I just googled Choosing a doctype and got this[1] excellent article - here's a quote. There seems to be a common misconception that the XHTML Transitional DOCTYPE is for developers to make a transition from HTML 4.01 to XHTML 1.0. It's utter nonsense, as the HTML 4.01 DTD and the XHTML 1.0 DTD are very similar in the rules they apply. The only difference is the well-formed issues that any XML application must adhere to, whether it's Transitional or Strict. So which is the better DOCTYPE? HTML 4.01 Strict, or XHTML 1.0 Transitional? Without a shadow of a doubt, the HTML 4.01 Strict DOCTYPE is a far better than XHTML Transitional, as it deprecates presentation elements such as font, and presentation attributes such as align. XHTML Transitional merely means you've ensured it's well formed. [1 ]http://www.juicystudio.com/choosing-doctype/ Of course the DTD's are different. I'm not saying that XHTML Transitional is some kind of siamese HTML 4 / XHTML Strict. As has already been stated, XHTML Transitional is, more or less, a reformulation of HTML 4. But XHTML Strict is where XHTML is supposed to be - cutting out the presentation and leaving just the structure. As we're all such fans of semantics, just think about the word 'Transitional' - it means something between two things. A bridge. A half way house. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] When the mix of visual appearance and meaning goes really bad
Absolutely! In natural science (specifically speaking about species names here) Italics are the way to present the scientific name (genus species pair or senior synonym like iThorunna australis/i or even just the species or shorthand variations), not emphasis. I think there is a good argument for using i here as it isn't ambiguous in any way that I want italics. In this case em is just semantically wrong and i simply should not be deprecated. Hmm. This is a difficult one. I think it could be argued that this is emphasis. In this case you are emphasising the species by displaying it in italics. i certainly isn't the way to go though with either argument - language is supposed to be independent of presentation, be it visual or aural or whatever. What if the biologists that be decided to change the way this was normally presented? What if it was deemed to be better to be in bold rather than italics? Your HTML would then be semantically incorrect. Hypothetical, but logical. I think it's right to completely separate meaning and presentation and I think it's right to deprecate i. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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: Ten questions for Anne van Kesteren
I thought XHTML transitional _is_ XML. In what way is XHTML transitional is a less strict data format? It's a transition. It's a half-way house between HTML 4 and XHTML as it is intended (XHTML Strict). Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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: Ten questions for Anne van Kesteren
I thought XHTML transitional _is_ XML. In what way is XHTML transitional is a less strict data format? It's a transition. It's a half-way house between HTML 4 and XHTML as it is intended (XHTML Strict). Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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: Ten questions for Anne van Kesteren
I thought XHTML transitional _is_ XML. In what way is XHTML transitional is a less strict data format? It's a transition. It's a half-way house between HTML 4 and XHTML as it is intended (XHTML Strict). Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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: Ten questions for Anne van Kesteren
I thought XHTML transitional _is_ XML. In what way is XHTML transitional is a less strict data format? It's a transition. It's a half-way house between HTML 4 and XHTML as it is intended (XHTML Strict). Are you saying that XHTML transitional is a less strict data format than XML too or are you off on some tangent? If the the former then please explain in it more detail, I really am under the impression that XHTML transitional is XML - that being so, in what way can it (XHTML transitional) be a less strict data format (than XML)? I *think* that the transitional aspect is related to the set of available tags, rather than it's XML suitability. A lot of behavioural/presentational tags and tag attributes were removed from strict, but left in for transitional. Whether XHTML is valid XML is beyond my knowledge, but I believe it is. Valid XHTML Transitional *is* valid XML, just as baboobaWahoo/babooba can be a valid XML element. It has rules to follow, just like any standard, so in that respect all standards are as strict as each other - you have to stick to the rules. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Validator Question re SHORTTAG YES
I'm not sure what this means actually. This is from a table in my code which is for tabular data, not for layout. ??? The validator won't know if a table's used for tabular data or for layout, so this doesn't come into it. Am I correct in assuming that the validator does not like the 'nowrap'? And that probably being the case, and since I do need it, is there some other betther method for pulling this off? 2. Line 65, column 23: the name and VI delimiter can be omitted from an attribute specification only if SHORTTAG YES is specified td width='10%' nowrapa href='#'Updated/a/td Try nowrap=nowrap Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] CSS: writing-mode
It uses the CSS attribute: writing-mode I havent heard, or seen this before... where did it come from? anyone know - or have any info about this? It's a Microsoft proprietary thing. Not valid. Only works in IE. Having said that, take a look at this CSS3 candidate recommendation: http://www.w3.org/TR/2003/CR-css3-text-20030514/#writing-mode Although I'm still assuming that your software is relying on the Microsoft implementation. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] Images inside a div class with specified link style
.divRight a
{
border-bottom : none;
}
Your code was looking for an a element nested inside an image!
If there are other links in .divRight boxes that you want the border
applied to, you'll need to apply a different class to the a element
surrounding the image.
Patrick Griffiths (PTG)
http://www.htmldog.com/ptg/
http://www.htmldog.com
How do I prevent link styles from showing on the images that are
positioned
inside a div class with specified link style? An example below.
div class=aCol
Content text here Content text here Content text here Content text
here
div class=divRight
a href=#img src=top.gif alt=Back to top of the page
width=30
height=10 //a
/div
/div
.aCol a
{
color : #AE0D2D;
text-decoration : none;
border-bottom : 1px dashed #90AAAB;
}
I have tried doing..
.divRight img a
{
border-bottom : none;
}
*
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] Lists in Paragraphs (was Custom DTD's to allow target attribute? Yuck)
Take the following sentence: Mark went to the store and bought eggs, milk, bread, chicken, rice, and corn. Doesn't that sentence contain a unordered list? Good point. I'm still not in agreement that ul/ol's should be nested in p's though. Maybe someone can clarify in the discussion how to view semantics in the context of this example. Dictionary.com's definition of 'paragraph': A distinct division of written or printed matter that begins on a new, usually indented line, consists of one or more sentences, and typically deals with a single thought or topic or quotes one speaker's continuous words. I read 'one or two sentences' as meaning not lists, so semantically speaking a paragraph can't have a list in it, but I see the argument. If I was concerned about Mark went to the store and bought eggs, milk, bread, chicken, rice, and corn. containing a list, I might do: pMark went to the store and bought:/p ul lieggs/li limilk/li ...etc... /ul I would tend to see that as 'continuous words' though, rather than an explicit list. Either way, I think the standard's got it right and you shouldn't nest ul's or ol's *in* a paragraph. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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 Form + Label - Errors
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.neester.com%2Ftdir%2F contact.phpcharset=%28detect+automatically%29doctype=%28detect+automat ically%29verbose=1 why is my page getting all these errors. It is asif I have forgotten to close a tag or something... Please help. You need to wrap your form elements in block level elements. Try wrapping them in div's. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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=_blank substitute
This is both an accessible and valid method: Valid yes, but accessible? I click on a link. I look at the page. I try to click on the back button. What? Why doesn't this work? Oh. Because it's opened in a new window. Close window. Return to the site (and page) I want to be on. This whole malarkey makes the site less accessible for me, let alone for a person who can't actually see what's going on. a href=foo.html onclick=window.open(this.href);return false; onkeypress=window.open(this.href);return false; title=opens in new windownew window/a If you are going to use JavaScript though, this will do: a href=foo.html onclick=window.open(this.href);return false; title=opens in new windownew window/a onclick is invoked by keyboard action too. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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=_blank substitute
You're right, Patrick, but life is a series of compromises. I spend a lot of effort in getting users to my site, and I don't want to go sending them away again with a link on my site. If they want to click on a link external to my site, they get a new window so their existing window stays in my site. It's not accessible, that's true, but if they stay inside my site, no new windows open. And I'm not going to go sending 97% of users out of my site with a link, just so 3% can have an accessible access to that one or two links. OK. Let's forget about accessibility for a moment then. The back button is one of the most commonly used navigational tools. By opening new windows you disable that feature. You're hindering usability and actually making it more effort for people to come back to your site. It's just not possible to lock people into your site. If they want to go away from it, they're going to. If they want to come back to it, that's great but keeping your site in the background isn't going to help that at all - they know they should be able to reach it by a 'click' or two of the back button. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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=_blank substitute
Many clients have been told time after time that for external links you should always open a new window this is going to be a problem for quite a while, until we can convince people this is not necessary, I believe that this or Justin's way of dealing with external links is a practical solution to a very real client problem. I absolutely agree. If we're talking about *having* to do it then we do it. But if we're talking about best practices it's a different matter. Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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] WAI3 in a strict DOCTYPE
I've run into a wall. I wasn't trying for WAI Level 3, but I've usually been pretty close to achieving it. Bobby always yells at me to specify the language of the document using the attribute lang=en in the HTML header. W3C tells me though that lang=en isn't a valid attribute. Do you have to pick between using transitional and getting WAI3 and using strict and at best getting WAI2, or is there a solution for this problem? Try xml:lang lang isn't valid in XHTML 1.1 http://www.w3.org/TR/xhtml11/changes.html Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.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 *
