Re: [WSG] PDFs and other non-html files opening in a new browser window

2009-02-05 Thread Lachlan Hunt

Carolyn Diaz wrote:

My Web team and I are discussing whether or not we should open links to PDFs
and other non-html pages in a new window. Someone cited Jakob Nielsen's
argument at http://www.useit.com/alertbox/open_new_windows.html as the
reason we should open in a new window. (We all work on government Web sites
and they are about to release a new set of linking standards.)


While Jakob is often right about usability issues, he is absolutely 
wrong about this.  His advise is based on an extremely limited 
understanding and faulty assumptions about the way PDFs work on many 
systems.


While the problems he cites have been well known issues with old 
versions of Adobe Acrobat, due to its slowness and defaulting to opening 
within the browser window in some browsers, that is not the case with 
all PDF viewers and browsers.


Depending on the combination of browser, PDF viewer, and the user's 
preferences, some open within the same browser window by default, others 
launch the PDF viewer in a separate tab by default and others launch the 
PDF viewer as a separate application.  If you attempt to force a new 
window, the many people in the latter case (especially Opera and Firefox 
users on Mac, for example) will end up with a new blank tab while the 
PDF opens in the PDF viewer.


The best way to deal with the situation is to clearly label the link as 
being PDF and let the user decide how they wish to proceed.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



[WSG] Re: As a web developer do you find the 'HTML5 the mark up language' a useful document?

2009-01-28 Thread Lachlan Hunt

Steven Faulkner wrote:

The the W3C HTML working group is currently debating the usefulness of
 HTML 5: The Markup Language http://shrinkster.com/13zy vs HTML 5
A vocabulary and associated APIs for HTML and XHTML
http://shrinkster.com/13zz as normative documents for web developers
to use as a reference point in their work.


Just to clarify the purpose of The Markup Spec, and to make the feedback 
from this discussion more useful, I'd like to provide a little 
background about the work going on within the WG that affects web 
developers.  There are two other documents being worked on within the 
HTML WG specifically targeted at web developers.



The Web Developer's Guide to HTML 5, which is being drafted by myself, 
intends to describe the vocabulary and scripting APIs in clear and 
simple language, without resorting to formal grammars like DTDs or Relax 
NG schemas, and to explain how to use the language and syntax.  The 
structure is more like a reference guide, rather than step-by-step tutorial.


http://dev.w3.org/html5/html-author/


A different type of document was begun recently and is being drafted by 
Dan Connolly.  This document is intended to be more of a step-by-step, 
cookbook-style guide to writing pages using HTML5, with a big focus on 
the multimedia aspects.  e.g. It will provide things like:


* How to embed a video within a page and provide customised controls 
using the DOM API,
* How to indicate the completion status of a web application using a 
progress bar.

* How to markup images with captions
* etc.

It currently in a very early stage of development and hasn't yet been 
published as an editors draft and so isn't available to see yet. 
Although you can review DanC's emails where he has provided an outline.


http://lists.w3.org/Archives/Public/public-html/2009Jan/0274.html
http://lists.w3.org/Archives/Public/public-html/2009Jan/att-0274/html-writing-ideas.html
http://lists.w3.org/Archives/Public/public-html/2009Jan/0308.html


On the other hand, HTML5: The Markup Language, which Steve referred to, 
is a document that describes just the HTML vocabulary and the conforming 
syntax primarily using Relax NG and incorporating some conformance 
statements directly from the HTML5 spec.  The Relax NG schemas come from 
the code used by the HTML5 validator, validator.nu.  So the document 
itself, IMHO, seems to be optimised for tool developers that have a real 
use for such schemas, rather than web developers who just want to be 
able to know how to write HTML5.


http://www.w3.org/html/wg/markup-spec/


Finally, the main HTML5 spec contains the full language spec and 
implementation details and conformance requirements.


http://www.whatwg.org/specs/web-apps/current-work/multipage/

As web developers, you'll mostly be interested in the following 
sections, which are the main ones that deal with the HTML vocabulary and 
syntax.


http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#semantics
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing-html-documents

Note that the WHATWG and W3C versions of the spec are identical in all 
the important ways, but the WHATWG has a multipage version that the W3C 
doesn't.  But for those, like me, who like the single page version, we 
have that too.


http://www.whatwg.org/specs/web-apps/current-work/

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5

2007-08-30 Thread Lachlan Hunt

Vlad Alexander (XStandard) wrote:

Brad wrote:
Omitting the alt attribute as a requirement may have a level of 
appropriateness for sites like flickr


Creating content on the Web that is only accessible by one group of
people is never appropriate.


That's technically true and even though sites like Flickr certainly 
should allow users to provide alternate text for their images, the 
question that still remains is that if allowing the alt attribute to be 
omitted when users don't provide any good text isn't the right solution, 
then what is?  What should the spec recommend to use in these cases?


Whatever the solution(s), there are various different scenarios that 
should be addressed.  (Note that in all of these scenarios, the 
authoring tools should allow the author to specify alt text. This is 
just about what to do when the author doesn't.)


What should an authoring tool (like Dreamweaver) insert by default when 
a user adds an image and immediately dismisses the alt text prompt?  (It 
currently omits the attribute unless the user explicitly selects 
"" or types in some text.)


What should wikipedia use by default for images used in articles?  (It 
currently redundantly repeats the image caption in both the alt and 
title attributes)


What should sites like Flickr, Photobucket, Facebook, MySpace, etc. 
generate and insert?


What should forums (e.g. phpBB) or blogs (e.g. Blogger) use?

What should an email application insert when a user emails an image to a 
friend?


--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Using target="_blank"

2007-07-24 Thread Lachlan Hunt

Ryan Lin wrote:
With the XHTML Strict DTD, forcing a new window to open for a link via 
target="_blank" is not a valid semantic method anymore. I myself believe 
that whether to open in a new or current window should be user decision, 
not wed designer/developer. If I am using Strict DTD, the only way to 
achieve opening the new window is through JavaScripts.


So what argument should I give to my clients not to use target="_blank" 
? If I say that won't validate your page, they won't care. So any 
non-technical argument that I can give to them?


That depends on the point you're trying to argue.  Are you trying to 
argue in favour of using javascript instead of target="" to get a new 
window, or against the use of new windows in general?  For the latter, 
there are plenty of arguments against using popups and I suggest you 
search the archives.  In particular, I know I have personally refuted 
ever single argument for popups in the past and don't particularly feel 
like repeating that again.


If, however, you just want to use JS to sneak the popup past the 
validator, then I think you're wasting your time.  If you're using 
popups, then getting approval from the validator is the least of your 
worries.


There are a wide variety of JS methods you can use to create popups, 
including these and their variations:


1. Using JS to add target attributes to links
2. 
3. Using unobtrusive JS to attach event handlers to links, which call
   window.open() when activated.

Depending on the specific method used, using JS to create popups can 
cause numerous problems.  Of those, #1 is just hiding the target 
attribute from the validator and basically misses the whole point of why 
the target attribute was forbidden in the Strict DTD.  However, compared 
with the other 2 alternatives, it is the lesser evil.


Using the target attribute (either directly in the markup or adding it 
with script) is a lot more user friendly than window.open().  Firstly, 
it is significantly easier for a user to configure their browser to 
ignore target attributes, than it is to override window.open(). 
(Personally, I do both, but disabling window.open() has some unfortunate 
side effects on some sites).


The target attribute also allows the browser to notify the user that it 
will open a new window.  Safari, for example, tells the user in the 
status bar when they hover over the link, and there are various other 
methods available for other browsers.


So the question really comes down to how important validation is to you 
and how much effort you're willing to put in to get the tick of 
approval.  Although I don't recommend popups if you can avoid them, if 
you must use them, I recommend just using the target attribute in the 
markup or, if the validator's tick of approval is really that important, 
you can accept the fact that you're just lying to it, and if you want to 
put in the extra effort, then add the target attributes using script.  I 
oppose any method that makes use of window.open().


--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: self-closing tags in HTML, was: [WSG] A CMS for POSH sites?

2007-05-29 Thread Lachlan Hunt

Alastair Campbell wrote:

On 5/29/07, Nick Fitzsimons <[EMAIL PROTECTED]> wrote:

The topic under discussion is, as I mentioned in my earlier post,
mentioned in HTML 4.01 at
<http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7>
as being something with poor support in HTML user agents.


Which I read, thank you, but unless I'm being particularly thick
(quite possible, it was a long weekend ;), I can't see how that
affects terminating characters. Without the SGML spec, what is a NET
character? It's just frustrating not to be able to get to the source
and find out what these things are.


SGML and HTML Explained by Martin Bryan [1] will explain everything you 
need to know about SGML.  In particular, chapter 4 explains the SHORTTAG 
NET features.  Figure 4.4 [2] lists the default delimiter characters 
from the reference concrete syntax, which includes:


   / NET Null end-tag

That can be set in the SGML declaration, but because it's not explicitly 
set in HTML4, it uses the default.


[1] http://www.is-thought.co.uk/book/
[2] http://www.is-thought.co.uk/book/sgml-4.htm#Fig4-4

--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: self-closing tags in HTML, was: [WSG] A CMS for POSH sites?

2007-05-29 Thread Lachlan Hunt

Alastair Campbell wrote:

On 5/29/07, Rimantas Liubertas <[EMAIL PROTECTED]> wrote:

http://www.w3.org/TR/html401/sgml/sgmldecl.html
FEATURES, SHORTTAG YES


I guess from that I should deduce that I do need to know the SGML spec
to know that a slash will terminate a tag?

I hope HTML5 does away with this...


HTML5 disposes of the myth that HTML is an application of SGML, so you 
don't need to understand SGML at all.  In fact, in HTML5, the trailing 
slash is explicitly permitted for void elements, though it's not 
necessary.  Void elements (formerly known as empty elements in SGML) are 
elements like , , , etc.


Thus, in HTML5, both  and  are permitted and mean the same 
thing.  The slash is ignored by the parser.  However, the slash is not 
permitted for non-empty elements.  e.g.  is not allowed in HTML, 
though it is in XHTML because XML rules apply.


--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] IE 7 body length problem

2007-05-08 Thread Lachlan Hunt

Thierry Koblentz wrote:

I don't see this behavior in ie7 WinXP Pro
But I think you should be able to fix what you describe by giving layout 
to some element in there.

Did you try: body {zoom:1}


Be very careful about overusing hasLayout.  It's not something that 
should just be gratuitously used everywhere you think there's a bug, 
particularly when you can't actually see a bug.  If used carelessly, 
hasLayout has the potential to cause more problems than it actually solves.


Hacks should always be a last resort, not something you turn to at the 
first sign of a bug.  It's always better if you can resolve the issue at 
source, instead of throwing random hacks at it until it's patched.


--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] markup for headline and tagline

2007-05-06 Thread Lachlan Hunt

Paul Novitski wrote:
What markup do you favor for a headline-tagline pair?  (The second 
element could be a tagline or a byline.)


Thundering Pigs
a blog by Bob


No, cite is for citations.


Thundering Pigs
a blog by Bob


Yes, I'd use that.

--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Valid and well-formed

2007-04-28 Thread Lachlan Hunt

Katrina wrote:
David Hammond suggests that validity is not well-formedness, in that a 
document can be well-formed and not valid, but could also be !!! valid 
and not well-formed.


http://www.webdevout.net/articles/validity-and-well-formedness#validity_well_formedness 


That article is actually only talking about the cases where the W3C 
validator has known XML limitations.  Despite the validator claiming the 
non-well-formed documents are valid, they are not.  If you use a 
validator that makes use of a real XML parser, the documents would not 
validate.


Page Valet has an XML parser available for validation.
http://valet.webthing.com/page/

--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Will HTML5 be a purely presentational language?

2007-04-28 Thread Lachlan Hunt

Laura Carlson wrote:
The following may be of interest to web standards folk who haven't been 
keeping up with the HTML Working Group and where HTML5 is headed:


On 4/26/07, Ian Hickson <[EMAIL PROTECTED]> wrote [1]:

There are people strongly arguing
that HTML should be a purely presentational language, much, much more
presentational than the proposed WHATWG draft...


[1] http://lists.w3.org/Archives/Public/www-html/2007Apr/0171.html


Hixie was probably referring to things like people asking for a new 
 element to replace .  Personally, I totally ignored 
that thread and few people took the idea seriously because the whole 
idea is nonsense.  HTML5 will not be becoming a presentational language, 
though it also won't be a strictly and purely semantic language either.


http://lists.w3.org/Archives/Public/public-html/2007Apr/0391.html

--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] commenting javascript in script tags

2007-04-26 Thread Lachlan Hunt

Andrew Harris wrote:

It is common and often recommended practice to comment javascript
placed in a document.


   <!--
   myVariable = 'woo';
   // -->



Don't bother using those comments, they're a waste of time.


The reason cited is that 'very old browsers' that do not understand
the script tag may print the raw code.

How old are we talking? Has anyone ever seen this happen? Can't we
safely leave behind what is essentially a hack?


Sadly, yes.  The browser embedded in a a particular mobile phone (I 
think it's the  Motorolla V3) does not recognise the script element and 
will render the script on screen if it's not commented out.  However, 
that phone and its browser have far more significant problems and is 
safe to ignore.


Other than that, any browser released since the mid-90's will recognise 
the script element and hide its content.



While I'm on the topic - what about the whole  thing?


No.  That is for use in XHTML only.  In HTML, the content of the script 
element is parsed differently from other markup.


See this article of mine for a more detailed explanation.

http://lachy.id.au/log/2005/05/script-comments

--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] colour matching transparent png files

2007-04-10 Thread Lachlan Hunt

twe melb wrote:

As far as i know png alpha transparency does not work well in IE 5.5 and 6,


Correct.


it seems to only works in firefox,


And IE7, Opera, Safari, etc.


i tend to avoid the use of png as it is not cross browser compatible,


Nonsense!  Aside from alpha transparency problems in IE6 (and earlier), 
PNG is widely supported.  PNG8 supports index transparency, just like 
GIF, and that is widely supported.  Alpha transparency can be used if 
care is taken to work around the limitations in IE6.



i  uses gif instead.


Don't use GIF, it is inferior to PNG in every way.  Animated GIFs are 
the exception, but they should be used sparingly anyway.


--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] namespace attribute and validation

2007-03-28 Thread Lachlan Hunt

James Ellis wrote:

a question about namespace attributes in html/xhtml. I'm looking at methods
of conveying information to client side scripts in a neat manner within an
HTML document and trying to be valid at the same time.
My methods works but the validator complains about namespaced attributes.

Method 1: Namespace attributes - works but doesn't validate

http://www.w3.org/1999/xhtml";
 xmlns:d="http://example.com/data";
 xml:lang="en" lang="en">




...



What's the actual problem or use case you are trying to solve by 
introducing namespaced attributes?  Your above description is rather 
vague.  Have you considered that there may be an existing microformats 
based method to solve your problem?


Note: "I want to use namespaced attributes" is neither a problem or a 
use case, it's a solution; but a solution to what exactly I am unsure. 
If you can provide more information about the use case or problem, then 
perhaps someone can offer a better alternative.



Method 2: multiple class names
a snippet ...

   
 
   foo

   


If you are intending to use this in HTML documents, then that kind of 
approach would be best.



I'd really like to use Method 1 as it's the cleanest and doesn't involve
unnecessary Javascript. The specs seem to allude to the fact that you 
can do this but the validator says no.  Does anyone have some ideas about

making it validate?


That's a limitation of DTDs and DTD based validation.  They are simply 
not expressive enough to describe namespaces properly.  The only way you 
could work around the validation problem would be to write your own DTD, 
but that would be an exercise in futility.  Given that you're using 
XHTML [1] and because browsers do not use DOCTYPE sniffing for XML 
content, you could just omit the DOCTYPE entirely and rely on better 
methods conformance checking and validaiton.


[1] I'm assuming by the fact that you think you can use namespaces, you 
are actually serving your documents as XML, and not text/html. 
Namespaces cannot be used in documents served as text/html.  If you do 
not understand this MIME type issue, namespaces are most certainly not 
the solution to your problem.


--
Lachlan Hunt
http://lachy.id.au/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Re: Website Directory Structure - Best Practice

2006-03-20 Thread Lachlan Hunt

Richard Czeiger wrote:
For example "Latest Mars News" for NASA, might be better served with 
havng an index page with a linked archive of static URLs, or permalinks 
for latest articles (like "/mars/news/060320.html").


I fully agree with what you're saying, but just have one minor issue. 
Dates in file names should always use 4 digit years (or more after 
y10k).  I'm sure you all remember the y2k bug, let's not suffer again 
with a y2.1k bug.  It's best practice to use ISO-8601 dates (with or 
without the hyphen), especially in file names and it has the advantage 
that sorting by name also sorts by date.


e.g. /mars/news/2006-03-20
Or maybe:
/mars/2006/03/20/article-title

--
Lachlan Hunt
http://lachy.id.au/
**
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: Website Directory Structure - Best Practice

2006-03-20 Thread Lachlan Hunt

Mark Harris wrote:

Richard Czeiger wrote:

Sorry Vlad - Ithink I'm with Lachlan on this one...

Docs can be edited or re-written but if they're obsolete, you don't 
need to delete them - just don't link to them...


Actually, Lachlan said "no URI should be deleted" which everybody has 
taken to mean "no document left behind" or some such. If a document 
becomes obsolete, remove it and redirect the URI to a page that notifies 
the user of the fact and offers a newer version. How many times have you 
used Google and got a 404 because someone had removed the document you 
were coming for?


And why would you have a document on your site that *wasn't* linked to?


Why would you cease linking to it from anywhere, even if it was only 
linked from some archive pages?


Can you in turn suggest a reason why you would retain a document on a 
site that was unlinked?


Because you don't know who else has linked to it from another site or 
bookmarked it.  Of course, if the page no-longer contains any relevant 
information, it has been superseded by another document with a different 
URI and is of *no historical value*, then the old one should be removed 
with a proper redirect to the new one (probably 301 Moved Permanently). 
 But in such cases, you should generally try to reuse existing URIs 
rather than setting up a new one.


There's a good example of this that I think I read in Cool URIs don't 
Change, where a weather page had ceased to be updated because it had 
moved to a new URI, but the old one remained without any indication of 
the new one being present.  In that case, they either should have 
retained the old URI or redirected to the new one.


But URI != document, necessarily, and an superseded document may be more 
dangerous than not finding anything.


I agree, but if documents are likely to be superseded by future 
documents, then they should have some status section that indicates meta 
data such as the publication date, the permalink of this version and a 
URI to retrieve the latest version.  e.g. Like the specs from the W3C 
do.  This does apply to commercial sites as well.


If you need evidence of why this is so important, how many times have 
you followed a link to an old news article from a few years ago, only to 
find that it has since been removed?  This happened to me recently with 
a news article on Yahoo news I think.  I can't remember what article it 
was or where I followed the link from, but it was rather annoying not 
being able to read it.


--
Lachlan Hunt
http://lachy.id.au/
**
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] Chinese translations and PHP includes

2006-03-20 Thread Lachlan Hunt

Adrian O'Hagan wrote:

I am using Dreamweaver for this - and you may well be right that it is an
editor issue.


In Dreamweaver, set the default file encoding to UTF-8 and use Unicode 
for all files.  Avoid using any legacy encodings.


Edit > Preferences... (or Dreamweaver > Preferences... on Mac)
Select the New Document pane.
Set the Default Encoding to UTF-8
Check "Use when opening existing files that don't specify and encoding"
Uncheck "Use Unicode Signature (BOM)" - Unfortunately, the BOM causes 
problems with PHP and other things, so it's safer to not include it.


--
Lachlan Hunt
http://lachy.id.au/
**
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] Chinese translations and PHP includes

2006-03-20 Thread Lachlan Hunt

Adrian O'Hagan wrote:

I am embarking on my first multi-lingual site (English, Simplified Chinese
and Traditional Chinese).

It is to be a static site (no databases) and I have used PHP to take
advantage of the server-side includes.


Although there's nothing wrong with using PHP, you don't need to for 
just server-side includes, you can just use SSI.

http://httpd.apache.org/docs/1.3/howto/ssi.html


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>


Unless you have a specific reason to use XHTML, it is advisable to use 
HTML 4.01.  It is also very advisable to use a Strict DOCTYPE, since the 
"transitional phase" is over.






Use 
Or, if you insist on XHTML, you *must* declare the xmlns and should use 
xml:lang as well.


http://www.w3.org/1999/xhtml"; xml:lang="zh" lang="zh">

However, it's far easier to just use HTML 4.01 Strict, since XHTML is 
far too complicated.  (When you switch to HTML 4, you must also stop 
trying to use XML empty element syntax)







Using the meta element with an http-equiv attribute set to anything 
other than Content-Type is completely useless.






Using the meta element with an http-equiv attribute set to Content-Type 
is completely useless for XHTML, you must use real HTTP headers.  For 
HTML, you should use real HTTP headers as the meta element is an 
inferior substitute.


http://lachy.id.au/log/2006/01/content-type

Additionally, you should consider using a Unicode encoding such as UTF-8 
or UTF-16.  AFAIK, PHP does not yet support UTF-16, so that leaves UTF-8 
which it can work acceptably with, as long as you avoid the Byte Order Mark.


See my 3 part guide to unicode:
http://lachy.id.au/log/2004/12/guide-to-unicode-part-1

For PHP, setting HTTP headers is as simple as adding this to the top of 
the template:





My major problem is this:  when I save the include, all Chinese characters
are rendered as a series of question marks.

http://www.digitaldogma.com.au/clients/helprequest/


That either means you have a character encoding issue, which is 
discussed in my guide to Unicode, or the fonts are not available with 
those Glyphs on your computer.  I suspect it's an encoding issue, but 
the computer I'm on at the moment probably doesn't have those glyphs 
either, so I can't be sure.


--
Lachlan Hunt
http://lachy.id.au/
**
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] Forward-slash suppresses word wrap in Windows IE

2006-03-20 Thread Lachlan Hunt

Thierry Koblentz wrote:

Paul Novitski wrote:

Workarounds: Preceding the slash with a BR tag works, of course, but
I haven't yet found anything else.

Try this:
P.demo2 {word-break:break-all}


Thanks, Thierry, but no go:

... It breaks between characters strictly at the block
width without regard for Latin-style word breaks.


I missed part of the question, I tought you just wanted to break the string,
no matter where...
Another solution would be to use IMG elements in there.


Better yet, use the character U+200B ZERO WIDTH SPACE (though, you'd 
need to check browser support)


--
Lachlan Hunt
http://lachy.id.au/

**
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: Website Directory Structure - Best Practice

2006-03-20 Thread Lachlan Hunt

Vlad Alexander (XStandard) wrote:
If you put all images into the "images" folder, it's like putting 
things into a black hole; things go it but never come out. The 
problem is just by looking at the files in the "images" folder, you 
have no idea which documents are referencing them so you are not sure 
if you can ever delete them.


Simple way to handle this:  Never delete them!  Since "Cool URIs don't 
change", no document should ever be deleted, and thus any document that 
does reference the image will still be there and require the image. 
Even if the document is edited to have the reference removed, it's still 
good to have it there for historical reasons and so that it may be used 
again in the future.


However, it can be very useful to categorise images into subfolders so 
that it makes it easier to find and use later.  I find dated folders is 
the most effective way to categorise images, which helps allow the URIs 
to be maintained perpetually.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Certified Usable

2006-03-19 Thread Lachlan Hunt

Steve Olive wrote:

On 20/03/2006, at 2:06 PM, Andreas Boehmer [Addictive Media] wrote:
Sydney-based Usability company PTG has made the claim that they can 
certify the usability of their websites:


http://www.usabilitynews.com/news/article3005.asp


I quickly validated their page with HTML Tidy (Firefox extension) and 
the page about "Certified Usable" has 2 errors and 44 warnings for 
""


That just shows how useless HTML Tidy is as a validator.  There are 
actually many more errors than that.  However, the article is talking 
about *usability*, not validity and their site may indeed be very 
usable; although I doubt it's very accessible.



(after getting past the 100 odd empty lines) with upper and lower case tags.


There's nothing wrong with using uppercase tags in HTML, although given 
that they use an HTML 4 DOCTYPE that triggers quirks mode, an xmlns 
attribute and XML empty element syntax, they really haven't got a clue 
what they're doing with markup.


--
Lachlan Hunt
http://lachy.id.au/

**
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 hacking.

2006-03-19 Thread Lachlan Hunt

Alastair Steel wrote:
We are an open source based software development company who deal mostly 
with SME businesses. We write mostly to the standards for CSS2 and 
deploy with Firefox, Mozilla or Safari. Not having to hack everything 
for IE has meant we can develop faster and cheaper.


Do you at least test the sites in IE to make sure they degrade 
gracefully and are fully accessible and usable, even if it doesn't look 
perfect?


We now have a potential client that, for reasons beyond reason, wants to 
use IE.


If you could find out their reasons for choosing to stay with IE, I'm 
sure those of us involved with either marketing and/or developing 
Firefox (or any other browser) could use the information to address 
their needs better.  Of course, it's likely that Firefox does already 
addresses their needs better than IE does and they just don't know it yet.



So my questions are?
i/ Is it possible to just look at the CSS which controls the layout of 
the whole app and just hack that for them. This is preferable as each 
user has their own language file which calls their language and CSS.


Whoever does it would need to see your HTML templates, CSS and any 
relevant JavaScript that modifies the DOM in ways that affect the rendering.


ii/ Or is it necessary to look at each page of the application (over 
100) and hack the CSS to make them work?


As long as the templates cover all the different kinds of markup and 
styles used, they won't need to see all pages.


iii/ Or worst case scenario are there changes that may be required in 
the HTML. (I don't see why as everything that is to be displayed in the 
app is in a DIV and all DIVs are controlled with CSS).


There's nothing special about div elements, they're just like almost any 
other element, except that they have very little default styling. 
Besides, statements like that make me think you may be suffering from 
divitis (or div-mania).


It may be as simple as using Dean Edwards' IE7 script or it may be as 
complex as doing a complete CSS overhaul.  However it's done, I'd 
recommend you just use a conditional comment rather than modifying the 
existing style sheets that alread work for other browsers.


iv/ If we go to all the trouble for IE 6 will it all work in IE7. Or is 
this going to be a separate hack.


There's no guarantee that anything will work in IE7 until the site has 
been tested in it.  It may or may not require additional hacks.  It's 
entirely possible that IE7 won't require any hacks for the site to work, 
but you won't know until it's been tested.  (AFAIK, the first IE7 
preview that isn't a complete joke will be released in a couple of days 
after MIX 06.)


I also need to work out the approximate costs of all the above so we 
can pass it on to the client. 


That depends on how much work is required, which depends on how bad it 
looks in IE and how good or bad the existing markup and CSS is to work 
with.  I suspect that whoever offers to take on this work will need to 
see it before they can give such a quote.


--
Lachlan Hunt
http://lachy.id.au/
**
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] Website Directory Structure - Best Practice

2006-03-19 Thread Lachlan Hunt

Lea de Groot wrote:
* the page-name.some-technology, in implimentation. I tend to end all my 
pages in html no matter what I am using server side because a) it says 
'webpage' and


Then it adds 5 unnecessary characters to the end of the URI that serve 
no real purpose.  I don't like including the file extension on any URI 
at all and if it wasn't for the annoying IE caching bugs I've 
experienced when leaving extensions of images, CSS and JS (i.e. IE 
apparently won't cache the files at all), I wouldn't include those either.


It's also annoying when changing implementation.  Like when I switched 
from blogger to WordPress.  Blogger used static .html files and gave no 
way to configure links to be written without file extensions, even 
though I had MultiViews turned on. WordPress stores everything in the DB 
and has no file extensions in URIs.


I ended up having to use mod_rewrite to accept .html on the end of any 
article URI so that no existing links/bookmarks wouldn't break.  It 
would have been much less hassle if blogger had let me turn off file 
extensions in the first place.



b) the technology for turning extensions off is flakey and


What's flaky about it?  Apache MultiViews is the easiest way to not 
require file extensions for static files, with the added advantage of 
making content negotiation extremely easy to do.


I find putting a single page per directory inefficient in workflow - it 
has to work on both the developers and the users side!


Yes, I agree with that.

--
Lachlan Hunt
http://lachy.id.au/
**
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] Website Directory Structure - Best Practice

2006-03-18 Thread Lachlan Hunt

Joseph R. B. Taylor wrote:

root web folder
-images


For images, styles and scripts these days I recommend using
/images/
/style/
/script/

When I initially built my own site, I put all of these under a /lib/ 
directory.  That can never be changed now, but on new sites I don't 
bother with that.


For images, I now use dated sub folders (just by year) for any images 
used in my blog articles.  That just keeps the number of images in one 
directory to a minimum, which makes them easier to manage.  Other images 
used in stylesheets or other general places throughout the site either 
go straight in the images directory or into subdirectories by category.



-main.htm


It's conventional to use index.* (.* represents any file extension you 
need) as the main index file on most web servers (IIS uses default.*) so 
that you don't need to include it in the URI.  You can configure it in 
your .htaccess file to main.htm, but why bother when it's easier to just 
use index.*


That way the URI just needs to be:
  http://example.com/
instead of
  http://example.com/main.htm

(It works the same for any subdirectories as well)


-events.htm
-bio.htm


Those are fine, but you should avoid including the file extension in the 
URI so that if you ever change the implementation from static HTML to 
JSP, PHP, ASP or whatever, the URI doesn't need to change just because 
the file extension does and then there's no need to set up redirects 
(which people often forget to do anyway).  If you're using Apache, 
turning on MultiViews is the easiest way to do that.


Recently I was hired to do some cleanup on a site I hadn't built and the 
directory was set up like:


[snip - directory structure]


Generally, you should try to avoid moving too much around, if anything 
at all, because doing so will end up changing URIs and that breaks 
bookmarks, links, etc.  If you do have to, make sure you set up 
appropriate redirects (using HTTP headers, never use  refresh)


--
Lachlan Hunt
http://lachy.id.au/

**
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] tabindex

2006-03-18 Thread Lachlan Hunt

Designer wrote:
In an endeavor to 'be good', I've been putting tabindex on links just 
lately.  Certainly the WAI validator gives me a warning if I don't.


Just ignore such useless warnings, tabindex can do more harm than good 
if used without a lot of care and it's mostly useless because there are 
few cases where tabbing through in document order isn't sufficient.



As it happens, the default taborder is the correct (desired) one anyway


Exactly why you shouldn't use it.


And what's the current thinking on accesskey?


accesskey is far worse than tabindex and many accessibility experts will 
tell you to never use it.

http://www.wats.ca/resources/accesskeysandkeystrokes/38

--
Lachlan Hunt
http://lachy.id.au/

**
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] Validating and validators

2006-03-16 Thread Lachlan Hunt

Kat wrote:
For a good while now I have been using A Real Validator to validate my 
html offline.


That's good.

1. What are your opinions of SGML-parsers vs linters? Do both have their 
place? Do they have different roles?


SGML parsers will tell you exactly what's wrong with your document 
according to the formal definition in the SGML declaration and the 
document's DTD and is the best choice for HTML documents.  SGML based 
validators for XML documents may have limitations (including any based 
on OpenSP, such as the W3C/WDG validators and A Real Validator).  Most, 
if not all, of these limitations relate to well-formedness errors which 
will be picked up by a browser when you use an XML MIME type anyway.


In general, lints are mostly quite useless for validation and they often 
lie.  Though some, like HTML tidy (which is one of the most useless 
tools for validation, IMHO), is still reasonably good at cleaning up 
really messy documents so that they can at least be worked with.



2. Is Validome an SGML parser or linter?


It's a lint.


3. How accurate do you believe is Validome's statement of errors?
http://www.validome.org/lang/en/errors/ALL


XML Declaration:
  All the errors not caught by the W3C validator are limitations with 
its XML support, but all of which are well formedness errors that will 
be caught by any decent browser when you use the correct MIME type.


Error in the Document Type Declaration:
All of the following are not caught by true SGML based validators, but 
that's because none of them are actually errors.  Any validator that 
chooses to raise these issues should call them warnings, not errors.


* System-ID missing (at PUBLIC) in HTML-Document
* Missing White Space between Public-ID and System-ID
* Upper and lower case at HTML-Documents
* Document Type Declaration in commentary area
* Unallowed overwriting of parameter entities
* HTML-Document with user-defined DTD
* HTML-Document with unknown Public-ID and user-defined DTD

I don't have time to go through the rest right now, I may do so later.

4. What is the most successful way in ensuring correct and valid html 
and or xhtml (considering different validators have different errors)?


For HTML:
  Use a real SGML based validator.  In general, I prefer the W3C 
validator, but the WDG validator's additional warnings that are not 
emitted by the W3C validator can be useful for making documents more 
compatible with real browsers.  e.g. it will give warnings about 
SHORTTAG NET usage (often just a result of XML syntax in an HTML document).


For XHTML:
  Make sure you develop and test the page using the correct MIME type. 
 That will catch any well-formedness errors immediately (including 
those not caught by the SGML validators).  Generally speaking, a 
validator that uses a real XML parser would be best, though the W3C/WDG 
validators are still very good, especially if you've already ensured 
against well-formedness that they won't catch.  The W3C/WDG validators 
will also give some useful warnings that a real XML parser won't, such 
as reference to a "non-SGML character".  That's very useful for 
detecting common mistakes like ’ instead of ’.


--
Lachlan Hunt
http://lachy.id.au/
**
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: Encoding test page

2006-03-16 Thread Lachlan Hunt

Keryx webb wrote:

xml-prologue


The XML Prologue is the section of the document that contains the XML
Declaration, DOCTYPE and any comments or PIs prior to the root element.
 The XML Declaration on the other hand, or (more specifically) the
encoding declaration within the XML declaration, is the special
construct that specifies the encoding and is what you're referring to.
Please try to get the terminology correct in future.

If a page is sent as XHTML, one could 
argue that it's supposed to be self-documenting, and that it might mean 
that the xml-prologue should be more important than the http-header.


See the Architecture of the WWW rec:
http://www.w3.org/TR/2004/REC-webarch-20041215/#xml-media-types

Information supplied at the protocol level always takes precedence over
anything specified in the file itself.  Therefore the HTTP Content-Type
header takes precedence over the XML declaration.

The precedence rules work like this for the following MIME types:

For application/xml, other application/*+xml
and application/xml-external-parsed-entity:
1. charset parameter in the Content-Type header
2. BOM
3. The XML declaration
4. UTF-8

The meta element is never used for determining the encoding.

For external parsed entities, it uses the Text Declaration instead of 
the XML declaration.  They're similar, but not exactly the same.


For text/xml and text/external-parsed-entity:
1. charset parameter in the Content-Type header
2. US-ASCII

The XML declaration and Text declaration is ignored.

For text/html:

a) According to the spec:
1. charset parameter in the Content-Type header
2. Meta element
3. charset attribute on the link followed to the page.

b) Actual browser implementation is a little unclear at this stage, it's 
not really well defined.  Here's a rough overview anyway:

1. charset parameter in the Content-Type header
2. BOM
3. Meta element
4. Unspecified heuristics (guessing)
5. Default (according to browser pref, which is usually ISO-8859-1 or
   Windows-1252)

I'm not sure if any UAs actually support the charset attribute for links 
at all.


--
Lachlan Hunt
http://lachy.id.au/


**
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] Semantic Form - Person's Title

2006-03-16 Thread Lachlan Hunt

Lachlan Hunt wrote:

Micky Mourelo wrote:

The legend is a required child of fieldset.


Specwise the DTD seems to say it is optional,




Looks like it's required to me...


and the validator agrees.


I'd like to see your test case that demonstrates that.


I forgot that this is one of those undocumented changes (i.e. not listed 
in section 4) between HTML 4 and XHTML 1:





So, technically, yes it's optional in XHTML 1.

--
Lachlan Hunt
http://lachy.id.au/

**
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] Semantic Form - Person's Title

2006-03-15 Thread Lachlan Hunt

Micky Mourelo wrote:

You don't need to set the for and id attributes when the input is within
the label because the association is implicit.


Not on IE. IE won't make the label clickable unless it is associated
through "for".


Of course not in IE, but IE is broken and I consider that acceptable 
graceful degradation.



The legend is a required child of fieldset.


Specwise the DTD seems to say it is optional,


Really?  Let's see:



Looks like it's required to me and it's the same in both Strict and 
Transitional DTDs.



and the validator agrees.


I'd like to see your test case that demonstrates that.

--
Lachlan Hunt
http://lachy.id.au/

**
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] Semantic Form - Person's Title

2006-03-15 Thread Lachlan Hunt

Micky Mourelo wrote:

...


You don't need to set the for and id attributes when the input is within 
the label because the association is implicit.



In this case you would set the labels to inline.

But in reality I would recommend either forgetting about the legend


The legend is a required child of fieldset.

--
Lachlan Hunt
http://lachy.id.au/

**
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: Encoding test page

2006-03-14 Thread Lachlan Hunt

Andrew Cunningham wrote:

Lachlan Hunt writes:

Andrew Cunningham wrote:
In theory the docuemnt should only be in one of the unicode 
encodings, so without a BOM, the browser should try to render it as 
UTF-8.


No, because when it's served as text/html, HTML rules apply, not XML 
rules.  So without the encoding declared in the HTTP headers or the 
meta element, the default of ISO-8859-1 should be used (if served over 
HTTP, technically US-ASCII otherwise).  However, browsers will 
actually interpret ISO-8859-1 as the Windows-1252 superset and will 
also attempt to use unspecified heuristics to guess the encoding, 
before falling back to the default.


If you're going by the HTTP specs.


Yes, of course, as well as the relevant RFCs for the MIME types.


If you go by the XHTML 1.0 recomendation, appendic C


Appendix C is non-normative.

would indicate that "... that when the XML declaration is not included in a document, the 
document can only use the default character encodings UTF-8 or UTF-16.:


That is only true for XML on the condition that the encoding has not 
been specified by a higher level protocol.  The relevant *normative* 
section of the XML rec. states in 4.3.3 Character Encoding in Entities:


In the absence of information provided by an external transport protocol 
(e.g. HTTP or MIME), it is a fatal error for an entity including an 
encoding declaration to be presented to the XML processor in an encoding 
other than that named in the declaration, or for an entity which begins 
with neither a Byte Order Mark nor an encoding declaration to use an 
encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, 
ordinary ASCII entities do not strictly need an encoding declaration.


http://www.w3.org/TR/REC-xml/#charencoding

The point I wnated to make is that there is another way to declare 
encoding for docuemnts in UTF-16 or UTF-32: and thats teh BOM; and that 
the test should also include BOM detection as an option,


Not according to the HTML 4 Rec, but...


i.e. do various  web browsers use the BOM as part of their heuristics.


In reality, yes.

--
Lachlan Hunt
http://lachy.id.au/
**
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: Encoding test page

2006-03-14 Thread Lachlan Hunt

Andrew Cunningham wrote:
I was wondering if you should have another test in there: XHTML document 
with no encoding declared in the http header or in a meta tag, and no 
xml declaration. Sent as html/text.


That's text/html and an XHTML document served as text/html is HTML, 
regardless of any lies the DOCTYPE tells you.


In theory the docuemnt should only be in one of the unicode encodings, 
so without a BOM, the browser should try to render it as UTF-8.


No, because when it's served as text/html, HTML rules apply, not XML 
rules.  So without the encoding declared in the HTTP headers or the meta 
element, the default of ISO-8859-1 should be used (if served over HTTP, 
technically US-ASCII otherwise).  However, browsers will actually 
interpret ISO-8859-1 as the Windows-1252 superset and will also attempt 
to use unspecified heuristics to guess the encoding, before falling back 
to the default.


--
Lachlan Hunt
http://lachy.id.au/
**
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] broken sprite - very odd ie6 thing

2006-03-14 Thread Lachlan Hunt

Ted Drake wrote:

I love using sprites, but I've never seen this happen before.

I've got a sprite that looks like this
[snip - useless ASCII art diagrams]


I think you'll find someone may actually be able to help you if you 
provide a link to a sample document (preferably a minimal test case) 
demonstrating the problem.  Besides, if you create a minimal test case 
(i.e. a document with the minimal amount of code possible to replicate 
the problem) you may even be able to solve it yourself.


--
Lachlan Hunt
http://lachy.id.au/
**
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)

2006-03-13 Thread Lachlan Hunt

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?


http://dbaron.org/log/2005-12#e20051228a

Is there some reason why absolute positioning has fallen by the 
wayside?


There are significant limitations with the use of absolute positioning 
such as the inability to create equal height columns and allow any 
column to have the longest content, which is one of the most common 
abuses of floats.


There are better approaches to layout being developed by the W3C, but 
they're still a very long way off from implementation.


--
Lachlan Hunt
http://lachy.id.au/
**
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: uppercase CSS and XHTML

2006-03-13 Thread Lachlan Hunt

Designer wrote:

Lachlan Hunt wrote:

Designer wrote:
Incidentally, I would be interested in any browsers you know which won't 
support application/xhtml+xml, apart from IE of course.


http://www.w3.org/People/mimasa/test/xhtml/media-types/results

Thanks, Lachlan. I studied the list, and the only failing browsers I saw were 
Opera prior to v7.10 (in some versions the type selector in style sheets matched 
case-insensitively) Amaya (well surely Amaya users are the type to upgrade to 
later versions, which are OK) and iCAB, the latter's only problem being the 
style sheet case mentioned above.


So, as far as I can see, if you have all your style sheets in lower case, the 
only problem is IE. If so, the selective feeding to IE should be fine.  Does 
anyone know why this wouldn't be the case?  If not, is this a new 'hack'?


No, because of the case sensitivity bug several browsers have 
(especially iCab) and the other reasons I mentioned before regarding 
browser Accept headers which would result in those browsers receiving 
HTML, not XHTML, and that would include users that have modified their 
browser's Accept header.  A browser's Accept header and its support for 
XHTML cannot be used as an indication of its CSS abilities.


In Firefox, this can be set with the pref network.http.accept.default 
and some users may have modified it to prefer HTML because of its 
inability to incrementally render XHTML.


iCab's accept header by default contains this:
  text/html;q=0.9,application/xhtml+xml;q=0.7

Safari's accept header contains just */*.  If you were using Apache 
Multiviews (which selects files based on the file extension and chooses 
the files alphabetically in the event that checking all other criteria 
didn't result in a single preference) then the .html file would be 
chosen over the .xhtml file.  Simply changing the file extensions to put 
the XHTML file alphabetically before HTML is not an option because then 
IE users would also receive the XHTML file.


Also keep in mind that that list is not a complete list of every 
browser, there may be others that don't support XHTML, do support 
stylesheets and are still in use by some people.


--
Lachlan Hunt
http://lachy.id.au/

**
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: uppercase CSS and XHTML

2006-03-13 Thread Lachlan Hunt

Designer wrote:
Incidentally, I would be interested in any browsers you know which won't 
support application/xhtml+xml, apart from IE of course.


http://www.w3.org/People/mimasa/test/xhtml/media-types/results

--
Lachlan Hunt
http://lachy.id.au/

**
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: uppercase CSS and XHTML

2006-03-13 Thread Lachlan Hunt

Designer wrote:

Lachlan Hunt wrote:
No, it will not work under XHTML at all.  The DOCTYPE is irrelevant, 
XHTML is case sensitive and uppercase element selectors will not match 
anything in XHTML.  It will only work for text/html.


OH Dear, I'm getting confused again!

When I read the above, I thought "ah - here's a fine way to feed IE only 
stuff perhaps",


That's a bad idea because IE is not the only browser that doesn't 
support application/xhtml+xml and some browsers actually prefer 
text/html according to their Accept headers.  So if your content 
negotiation was done correctly, such browsers would also get the 
text/html variant and, thus, your IE only styles.


so I did a simple experiment using the php generated 
headers trick mentioned by joshua [2].  I put the CSS as:



#container {width : 400px; margin : 0 auto;}
#content {padding : 25px}
#CONTAINER {WIDTH : 700PX;}



Those are ID selectors, not type (or element) selectors.  See my 
previous post for a discussion of why that doesn't match.


If you did want to use this technique, though I don't recommend it, you 
could use this instead:


#container { /* (X)HTML styles */ }
HTML #container { /* text/html only styles */ }

Note: that won't work if your non-conformant XHTML root element is:

http://www.w3.org/1999/xhtml";>
  ...


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-03-13 Thread Lachlan Hunt

Jason Turnbull wrote:

I was a bit unsure too as I thought the term 'selectors' in style sheets
referred too all tags, ids & classes,


Selectors are patterns that match against elements in a tree.  They 
include the universal selector, type selectors, class selectors, ID 
selectors, attribute selectors, pseudo-classes and pseudo-elements



talking about uppercase tags in CSS (h1, p ect)


They are not "tags", they are *type selectors* which match an element 
based on its type (or tag name).



From what I tested and according the link Philippe posted uppercase
identifiers are ok


Yes and no.  It is perfectly acceptable to write type selectors, ID 
selectors and class selectors, etc. in upper case; but whether or not 
they match anything in the document depends on the case sensitivity of 
the markup language.


Thus, all of the following are valid selectors:

P /* Matches an element of type P */
.FOO  /* Matches an element whose class is "FOO" */
#BAR  /* Matches an element whose ID is "BAR" */

In an HTML document, tag names are case insensitive and so P will match 
either of the following; whereas in XHTML, tag names are case sensitive 
and so will only match the element with the upper case tag name:

  
  

However, all elements in XHTML are defined as lower case and so the 
uppercase  is an undefined element.  Thus if a document included the 
uppercase tag-name, the document would be invalid but the uppercase type 
selector would still match it.


According to the HTML4 Recommendation and browser implementations (but, 
technically, not according to the rules specified by SGML and expressed 
in DTD) id attribute values are case sensitive and since XHTML is all 
case sensitive, #BAR will match:

  
but it will not match:
  

Class attribute values are also case sensitive in both HTML and XHTML 
and so .FOO will match:

  
but it will not match:
  

--
Lachlan Hunt
http://lachy.id.au/

**
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: innerHTML

2006-03-13 Thread Lachlan Hunt

Joshua Street wrote:

On 3/13/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

Joshua Street wrote:

any elements in the inserted content _aren't_ created as
elements, and hence cannot be manipulated at all.


Um... What the?  Of course they are created as elements,


They're "created", but, as I understood it, doesn't exist as part of
the document tree. (Which generally isn't any great problem if you've
decided to use innerHTML anyway!) That is, you can't use the DOM
methods to manipulate the nodes within that innerHTML fragment, even
if you've put IDs into the rendered source.


Sure you can, there's no reason why one shouldn't be able to.


Testing innerHTML



var foo = document.getElementById("foo");
foo.innerHTML = "<em id=\"bar\"><\/em>";
var bar = document.getElementById("bar");
bar.appendChild(document.createTextNode("PASS"));


There may be bugs that prevent some things from working correctly, but 
such things are just bugs, not restrictions on the feature itself.


--
Lachlan Hunt
http://lachy.id.au/

**
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: innerHTML (was: Re: [WSG] CAPS in stylesheets)

2006-03-12 Thread Lachlan Hunt

Joshua Street wrote:

On 3/13/06, Jay Gilmore <[EMAIL PROTECTED]> wrote:

I have also read (no personal first hand knowledge) that there can be
issues between using DOM/DHTML scripts and XHTML. I don't know what
these issues are but why invite trouble.


This arises from non-DOM methods, which are often much simpler to
implement (and faster in terms of performance), such as innerHTML [1]
(and document.write, but we won't go there). I *think* this is because
innerHTML/outerHTML/document.write and their kin leave the XML tree
alone -- any elements in the inserted content _aren't_ created as
elements, and hence cannot be manipulated at all.


Um... What the?  Of course they are created as elements, or at least 
they should be, unless you're talking about some strange IE bug I'm not 
aware of.  (I never use innerHTML so I'm not aware of all of its quirks.)


AIUI, the way innerHTML is supposed to work is that the value is parsed 
as HTML or XML (depending on whether the document is HTML or XHTML; 
which is determined by the MIME type, not the DOCTYPE) and a DOM 
DocumentFragment is created.  If it's XHTML, it should result in an 
error when the value is not well formed.  Mozilla does this, but Opera 
doesn't because it always parses it as HTML.  I'm not sure about other 
browsers.


All children of the element are then removed from the tree and the new 
DocumentFragment is appended.  I believe Mozilla internally uses its 
proprietary range.createContextualFrament() function to do this.


(That aside, I don't really see anything wrong with this [innerHTML] -- we must remember 
that XMLHttpRequest object is also proprietary!)


The problem is not that it's proprietary, there is actually work to get 
it standardised as part of the WHATWG's Web Apps proposal.  The problem 
I have with it is that it's working with strings to manipulate the DOM, 
and those strings need to have escaped characters which get's quite 
messy, much like document.write(), but not quite as bad [1].


For instance, just to write one simple element with an attribute, it 
needs to be like this:


  ...
  foo.innerHTML = "<p class=\"bar\">text<\/p>"
  ...


My other problem with it is that it's specific to (X)HTML, not any 
generic XML like the rest of the DOM API is (except for, of course, DOM 
2 HTML).  IMHO, Mozilla's createContextualFragment() is much more useful 
for any DOM and I would like it to be standardised, but I don't see that 
happening any time soon.


A much better alternative is to use E4X which is specially designed to 
make working with XML very easy, as XML is a native data structure, but 
support is currently too limited for real world usage.


[1] document.write() is bad because of the way it throws more markup 
back to the parser during parsing which means instead of having a nice 
flow like this:


input --> parser --> tree constructor --> output (DOM)

document.write() makes it more like this:

input --> parser --> tree constructor --> output (DOM)
 ^|
 |___doc.write()__|

--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-12 Thread Lachlan Hunt

Joshua Street wrote:

(with the exception of our esteemed friend Internet Explorer, which
doesn't even attempt to render pages served as anything other than
text/html).


...or text/plain. But that's another can of worms :-)

--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-12 Thread Lachlan Hunt

sime wrote:
No, it will not work under XHTML at all. The DOCTYPE is irrelevant, 
XHTML is case sensitive and uppercase element selectors will not 
match anything in XHTML. It will only work for text/html.


I have never had a problem with the uppercase not working in strict. 
Maybe I'm not defining strict correctly. Here is a test page which 
works in FF,IE6: http://urbits.com/_/test.php


Add this function call to the top of your PHP file:



--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-12 Thread Lachlan Hunt

sime wrote:

Christian Montoya

HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you
must write your CSS selectors in lowercase.


So that would make HTML4 practically redundant for new web sites?


What?  I don't understand how you came to that conclusion.


To Lea de Groot:
It worked in Strict which is why I've been misled for so long.


If you're talking about XHTML 1.0 Strict, then it will only work if 
you're using the wrong MIME type: text/html.  Serve your page as 
application/xhtml+xml and I doubt it will work.


--
Lachlan Hunt
http://lachy.id.au/
**
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: digest for wsg@webstandardsgroup.org

2006-03-12 Thread Lachlan Hunt

Lea de Groot wrote:

sime wrote:
However, I'm told that my code is therefore not XHTML compliant 
because of my use of uppercase. So who then is HTML4 relevant to?


I don't really understand the question.
As written, the css shown will work under HTML dtds (and XHTML 
transitional? I'm not sure as I never use it) but not XHTML strict DTDs.


No, it will not work under XHTML at all.  The DOCTYPE is irrelevant, 
XHTML is case sensitive and uppercase element selectors will not match 
anything in XHTML.  It will only work for text/html.


To make it work correctly for XHTML strict, you should change each tag 
name to lowercase.

Its a trivial change.


There's little point for authors to use that stylesheet, it is intended 
as a guide for browser implementors and was supposedly based on the 
default styles applied by browsers at the time.  (Although there are 
still many differences between that stylesheet and real world browsers)


--
Lachlan Hunt
http://lachy.id.au/
**
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] Some studies about web standards usage (sites of Estonia and W3C members)

2006-03-12 Thread Lachlan Hunt

Rene Saarsoo wrote:

http://triin.net/2006/03/05/Validating_sites_of_W3C_members


This article states:

| Character encodings
|
| 111 pages had no encoding specified in HTML. Of course not a
| requirement, but belongs to a good style.

Wrong.  It is a requirement to specify the character encoding correctly. 
 It would be useful if your statistics indicated not only what 
encodings were used, but whether they were specified in HTTP headers, 
the meta element, the XML declaration or a combination of them, incl. 
how many did so for each MIME type and how many had conflicting values.


Regarding the list of DOCTYPEs, it would be useful if you indicated 
which HTML ones included the System Identifier so that it is possible to 
determine which ones trigger standards mode, almost standards mode or 
quirks mode.  For example, in Mozilla, HTML 4.01 Transitional will 
trigger quirks mode without the SI and almost standards mode with the SI.


--
Lachlan Hunt
http://lachy.id.au/

**
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] page break when printing

2006-03-10 Thread Lachlan Hunt

Jack Pivac wrote:

on 10/03/06 13:56 Lachlan Hunt said the following:

I have a page with about 20-30 div's each about 200-300px height.


With that many, you may be overusing/abusing the div element.  [...]
You should probably try and find more semantic elements.


So in this case
http://temp.delphinus.co.nz/tab/test.html


In that case, the  look acceptable, the rest don't. 
Although besides the divs, there are some other things I'd be more 
concerned about.


Firstly, the page doesn't have a DOCTYPE so it doesn't validate.  Using 
the DOCTYPE override on the validator, it will validate as HTML 4.01 
Strict, but it's not really conformant and there are other issues.


From the source of that page:


Alex11223


That should probably be an .  Lose the .



  12345677 - Office
  01234567 - RSO Dial



"right" is a presentational class name, perhaps "phone-numbers" (or 
whatever they are) would be a better alternative.  It also looks like 
it's a list of phone numbers, so mark it up as a list.



  12345677 - Office
  01234567 - RSO Dial




  Last PM in August 2005



What's the extra  for?  This div would probably be better replaced 
with a  element and lose the style attribute, since it's presentational.


Last PM in Augus 2005



Joe Blogs

7-13 House st


XHTML syntax in HTML document.  It will validate but its meaning in HTML 
is different from that in XHTML, although browsers don't support it.



Alexandra


This whole address would be better marked up with a  element, perhaps 
given an appropriate class attribute, and remove the 2 extraneous  
elements from the end.  (use of  would be wrong)



Joe Blogs
7-13 House st
Alexandra


DDI - 1/11
LN/Group - 3111/1
UGEN# - 1
Office ID - omgofc


This looks like a list () or maybe a definition list.





According to the spec and the HTML 4 DTD, that border attribute is 
shorthand for frame="border".  However, browsers will incorrectly treat 
it as border="1".  That is why the page validates, but it doesn't mean 
what you thought.  Both are also presentational attributes and would be 
best replaced with CSS.



  
Terminal1Terminal2OFCPrinter


This could be marked up within a  element and the s replaced 
with .



  
CM0111CM0111CM0111CM0111
  



The rest of this table looks fine.


Rarely Used Spares - 211
Not Used Spares - 0


Looks like another list; or at the very least a .

--
Lachlan Hunt
http://lachy.id.au/

**
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] page break when printing

2006-03-09 Thread Lachlan Hunt

Jack Pivac wrote:

I have a page with about 20-30 div's each about 200-300px height.


With that many, you may be overusing/abusing the div element.  It's a 
common mistake, often referred to as "div-mania" (or something along 
those lines).  You should probably try and find more semantic elements.


Unfortunately when printing they sometimes get divided between 2 
pages... is there any way round this?


http://www.w3.org/TR/CSS21/page.html#propdef-page-break-inside

--
Lachlan Hunt
http://lachy.id.au/
**
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 ?

2006-03-08 Thread Lachlan Hunt

Kevin Ross wrote:

On the topic of the IE6 specific rules...

  

... is there a way to put that whole section in my Style sheet file?


The conditional comment needs to go within the HTML, since it is an HTML 
comment.  There are no conditional comments in CSS.  You could place it 
in an include file of some sort, which gets included in every file. 
For that, you could use SSI or, if you're using PHP, ASP, JSP, or 
something like that, you can use their own include functionality.


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-03-08 Thread Lachlan Hunt

Thierry Koblentz wrote:

I think it worth mentioning that the * html hack works in IE *Mac* too.


I forgot about this earlier, but that's the reason for the comment hack 
to hide from IE5/Mac.


/*\*/ * html { ... } /**/

--
Lachlan Hunt
http://lachy.id.au/
**
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] tags

2006-03-08 Thread Lachlan Hunt

Nick Lazar wrote:

Can anyone tell me what the current state of play is with the  tags
& XHTML?


You only need to write  in XHTML or, if you need to be compatible 
with Appendix C, .  If you use HTML instead, then you only need .



They seem to be the answer for a particular design I'm working on, and they
don't appear to be marked for deprecation.


It may or may not be the best solution, but we can't really advise on 
the situation unless you explain the use case.  Many common uses of HR 
would actually be better done with a top or bottom border, but there are 
still many valid use cases for HRs.



Are there any compelling reasons not to use them? (Apart from them being
empty tags).


Why would the fact that it's an empty element be a reason not to use it?

--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-07 Thread Lachlan Hunt

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 I think some unwanted hacks applying to it 
would be the least of its problems.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-07 Thread Lachlan Hunt

Paul Novitski wrote:
My point was simply that IE's conditional comments -- and ugly they are, 
no argument there -- are more likely to work as intended in a few years 
than hacks like * html.


* html hacks will continue to work in IE6 forever, just as they do 
today.  We already know this filter has been fixed in IE7 (standards 
mode), and so the following are exactly equivalent:



* html foo { ... }

(In the case of IE7 quirks mode, * html will still apply whereas the 
conditional comment would not.  In fact, since IE7 quirks mode will be 
very close to IE6 quirks mode, * html would be better because it would 
be very likely that the patch will still be required.)


So, any argument that stating that conditional comments are more future 
proof is a myth.  In fact, if you're not careful with conditional 
comments, they can be more dangerous.  Consider the following:


* html #content { height: 1%; }



The * html hack will only apply to IE 6 and earlier.  That particular 
conditional comment will apply to all versions of IE since IE5 (when 
conditional comments were first added).


If IE7 fixes the limitation from IE6, I'm sure you would agree that the 
patch should not apply to IE7 and, therefore, the use of a filter which 
does not apply to IE7 is the better option.


The most effective future proofing method we have is to ensure that any 
hacks we do use today do not inadvertently target any future browser. 
It is better for future browsers to receive fully standards compliant 
CSS, then for them to apply patches intended for and only tested in 
current browsers.


If the fate of * html was not yet known then I would agree that 
conditional comments with a version number specified are safer, but 
since we do know that * html is equivalent to [if lte IE 6], both are 
completely safe.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-07 Thread Lachlan Hunt

Seona Bellamy wrote:

On 07/03/06, Darren West <[EMAIL PROTECTED]> wrote:

I would advise against * html hacks though -
http://www.webstandards.org/buzz/archive/2005_12.html#a000598


I tend to disagree with such nonsense.  * html is a completely safe 
filter to use now that we know IE7 will not be supporting it in 
standards mode.  Therefore, for any IE6-and-earlier only hack, it is 
perfectly safe to use it.  IE 7 will then receive the same styles as all 
other browsers.  If it turns out that the limitation is still present in 
IE7, the filter will need to be modified to target IE7 as well, but 
until we know for certain whether it is or not, we cannot safely target IE7.



Put it in a conditional comment instead. Then you can even target IE6
specifically, and everyone's happy. :)


I have already used a conditional comment in this particular site 
because few hacks I had used were still required in IE7b2, but that was 
before I realised that IE7b2 was nothing more than a joke and I probably 
shouldn't have bothered with it.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-03-07 Thread Lachlan Hunt

Al Kendall wrote:

The attached pic is a screen shoot from IE 6.   Firefox 1.5 was fine


Yes, I know.  I think you misread my e-mail.  I knew it was broken in 
IE6, I'm looking for a way to fix it.  Any ideas?


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-03-06 Thread Lachlan Hunt

Philippe Wittenbergh wrote:

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 .


Great!  But I still need a solution to fix it in IE6.

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).


That's acceptable, IE/Mac is obsolete now anyway, so as long as the page 
is readable, I'm not concerned.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Styling Fieldset and Legend Elements

2006-03-06 Thread Lachlan Hunt

Hi,
  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

--
Lachlan Hunt
http://lachy.id.au/
**
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] Question of CSS specificity

2006-03-05 Thread Lachlan Hunt

Barrie North wrote:

I need some help, what is the difference between:
 
table.module


Specificity: 0,0,1,1


and
.module


Specificity: 0,0,1,0


Is table.module just more specific or is there more going on?


The former will only select tables with the class name "module".  The 
latter will select any element with the class name "module".


e.g.




They will all be selected by .module, but only the table will be 
selected by table.module



Similar question between:
a.contentpagetitle:link


Specificity: 0,0,2,1

That will select
link


and
.contentpagetitle a:link


Specificity is the same, but will select differently:


  link


(The  element could be any ancestor element)

--
Lachlan Hunt
http://lachy.id.au/
**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Felix Miata wrote:

On 06/02/20 06:32 Lachlan Hunt apparently typed:


[someone else] wrote:



Or better: Is there a way to please both groups?



Yes.  Don't use small fonts.


Don't blame me, I wasn't the designer, just the implementer so I had to. 
 But I also wrote somewhere else in that thread that I wouldn't go 
below 'small' for main content and that's exactly what it is.



On 06/03/02 10:31 Lachlan Hunt apparently typed:


http://edentiti.com/create/
[1] http://edentiti.com/


http://edentiti.com/style/design.css has '#container {...font-size: 
small;}', which makes for a _lot_ of small P text.


Issue #2:
http://juicystudio.com/services/colourcontrast.php tells me 'strong 
strong { color: #F90}' on white is inadequate color difference and 
brightness, and #069 on white just barely makes it.


I'll let the designer know.


Issue #3:
http://mrmazda.no-ip.com/SS/lachh1.jpg

Even at 1280x960 w/ my 20px default there the text for the left images 
is obviously not landing where you want. Seems like simple images like 
those you could grow with text size to keep things in place.


I'll look into this problem later.

Thanks.

--
Lachlan Hunt
http://lachy.id.au/

**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Kim Kruse wrote:

Hi Lachlan,

Just a design opinion...


Ok, I'll pass it on to the designers.

The main area (#main) looks a little "squeezed" between the rather heavy 
right and left sides. Maybe make the h2 bigger and


I know.  It worked better when there was less introductory text on the 
homepage.



make the intro below strong. (It is, but double strong!!...


important text (styled in blue)

very important text (styled in orange)

It was the most semantically correct way I could find to markup the 
different levels of importance.  There's are other combinations of 
nested  aswell (see the stylesheet).



I don't know if that's why it doesn't come up as strong on my screen (W2K/FF 
1.5).


Not sure what you mean by that.


Also the #main text is not the same size on all pages!


It's only different on the homepage (by design), everything else is the 
same.



IMO the text would stand out more if you used the darker blue from the 
logo instead of the paleish blue you use right now.


Ok, I'll let the designer know.

If the text is increased the text in the boxes on the 
left side "drops out" of the bg img. Maybe Thierrys TIP would work nice 
here?


What's Thierrys TIP?

Besides that I looks great... and I'm crazy over the form validation. 
Looks awesome.


Thanks.

--
Lachlan Hunt
http://lachy.id.au/

**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Joseph R. B. Taylor wrote:
Only thing I noticed is that the subpages' text size appears a bit 
different than the homepage text.  You may want to go with one size 
throughout the site for consistency.


That was the designers' decision.  Like the difference with the logo 
positioning, it was decided that the home page should have a larger and 
different colour text.  It was originally designed with less text (about 
1/3 of the current amount) on the homepage and looked ok with it, but 
now there's more I'd tend to agree it should just use the same as the 
rest, but it's not my decision.  I'll be passing on all of this feedback 
to the others for review anyway and see what happens.


--
Lachlan Hunt
http://lachy.id.au/

**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Tom Livingston wrote:



On 3/2/06 10:31 AM, "Lachlan Hunt" <[EMAIL PROTECTED]> wrote:


[1] http://edentiti.com/


Took _minutes_ for the home page to display, and once it did, it still
wasn't finished loading "things".

Mac OS 10.4.5 Safari 2.0.3


Really?  Maybe the server can't cope with the load very well, it's loads 
just as fast in Safari for me, as it does in everything else.  I find IE 
slightly slower because of the IE7 and the DOM patch scripts 
initialising, but nothing too serious.


--
Lachlan Hunt
http://lachy.id.au/

**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Gunlaug Sørtun wrote:

Lachlan Hunt wrote:

[1] http://edentiti.com/


The layout can't cope with any degree of font-resizing in any browser,
which I think is a weak point.


In my testing, I can resize a substantial amount before seeing any 
problems occur, and even then it's just slightly misaligned background 
images which don't affect the readability of the content too much.  The 
text will eventually over lap the columns (especially on the 3-col home 
page), but it has to get quite big and I'd rather the user disabled 
stylesheets in such cases or we provided an alternative larger 
font/single-column stylesheet.



Noticed delay (on a slow connection) for those '#secondary-nav'
background-images to change on :hover first time. Maybe a single
repositioned background would work better..?


That was considered and even attempted, but I couldn't find a way to do 
it in a way that didn't cause other problems without spending too long 
on the issue.  Now that I have more time, I may be able to find a way to 
do it.



PS. I know the markup is currently XHTML and I'm aware how much of a
 hypocrite that makes me :-)... plans to convert it to HTML4 later on.


Not much of an issue :-)
However, are there any reasons for not using '(X)HTML Strict' on that
page/site?


Yes.  The JavaScript and CSS were not fully written to deal with real 
XHTML issues.  With the exception of the DOM script from my library 
which was written to handle both conditions, the rest wasn't designed 
and tested under XML conditions because my original templates used HTML 
4 Strict.


It wasn't until the back end developer came along later and was only 
relatively new to programming JSP/JSF, we ended up having to accept the 
default output of XHTML in favour of fixing the other more major issues 
including invalid/ill-formed and inaccessible generated markup.


--
Lachlan Hunt
http://lachy.id.au/

**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Rob Mientjes wrote:

On 02/03/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

Hi Everyone,
   A new site I recently developed the front-end for over the past few
months, called Edentiti [1], has just officially launched and I wanted
to get some feedback...


Looks good, everything works. Just not sure about the logo and left
chunk of site. Why is that below the header bar?


It was decided by the designer and management that they wanted the logo 
on the homepage to be slightly larger and more prominent as a branding 
exercise, but to then move it up to the header, out of the way for all 
the sub pages.



Is that just Safari or was it a conscious decision?


Concious decision, all browsers.


Also, a typo on the about page says "About Edentit"—think of all the
children that will grin gleefully.


Couldn't find that typo anywhere.  Which page?  Give the URI.

--
Lachlan Hunt
http://lachy.id.au/

**
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 Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Hopkins Programming wrote:

Why must I have javascript enabled for the site to be styled?


Um... You don't need to, although IE users without script enabled with 
have a slightly degraded style (not totally unstyled) due to Dead 
Edwards' IE7 script not working.


Which browser are you testing with?  I couldn't replicate this issue at all.

--
Lachlan Hunt
http://lachy.id.au/

**
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] Site Check/Launch: Edentiti.com

2006-03-02 Thread Lachlan Hunt

Hi Everyone,
  A new site I recently developed the front-end for over the past few 
months, called Edentiti [1], has just officially launched and I wanted 
to get some feedback about the usability, accessibility and over 
functionality in whatever browsers you can get your hands on.  I've 
tested in various Windows and Mac browsers during development, but as is 
always the case, bugs tend to sneak in wherever they can and something 
may have been missed.


(I know there are bugs in IE7, but I'd rather wait till MS actually 
release something that isn't a joke like both betas 1 and 2 were before 
I bother testing/fixing with it - the one to be released after Mix '06 
looks slightly more promising)


For all you DOM Scripting fans, if you go to step 2 of the Create an 
Edentiti section, there's a funky form validation script you might want 
to check out.

http://edentiti.com/create/ (click next, to get to step 2)

[1] http://edentiti.com/

PS. I know the markup is currently XHTML and I'm aware how much of a 
hypocrite that makes me :-), but, given the time constraints, it was a 
limitation of the back end solution we had to accept, with plans to 
convert it to HTML4 later on.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Linking to top of page

2006-02-27 Thread Lachlan Hunt

Ian Anderson wrote:

Lachlan Hunt wrote:

It depends where the H1 is positioned.  If it's not at the top, the 
page won't be scrolled to the top.


If the H1 isn't at the top of the content, then I'd say there's a pretty 
good case for saying that the H1 is in the wrong place.


I meant not at the top of the rendered view.  i.e. It's been positioned 
using CSS.  Try this simple test case:



#foo { margin: 100px 0 1000px; }
Hello
top

--
Lachlan Hunt
http://lachy.id.au/

**
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] Linking to top of page

2006-02-27 Thread Lachlan Hunt

Paul Novitski wrote:

At 05:35 AM 2/27/2006, Curby wrote:

What is the recommended way for linking back to the top of the page? I
can't link to the id of my H1 because of my CSS.


Whoa.  Stop right there.  How can CSS stop you from linking to an h1 
that's got an id?


It depends where the H1 is positioned.  If it's not at the top, the page 
won't be scrolled to the top.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Linking to top of page

2006-02-27 Thread Lachlan Hunt

Curby wrote:

What is the recommended way for linking back to the top of the page? I
can't link to the id of my H1 because of my CSS. The name attribute of
the A tag is deprecated/removed[1].
...
[1] http://www.w3.org/TR/xhtml11/changes.html#a_changes


It's only deprecated in XHTML 1.1, which you almost certainly shouldn't 
be using anyway since it's really not supposed to be served as 
text/html.  If you really want to jump on the XHTML bandwagon, stick 
with XHTML 1.0.



And while some people might say "use the scrollbar or press Home"


That's always possible and why I never bother with back-to-top links.


1) Giving my BODY id="top" and linking to that seems to work but might
not be widely supported.


I'm not aware of any browser that doesn't support it, though it's 
possible some older browsers may choke on it.  If you use a container 
element around the whole content, you could use that instead:



  
... content ...
top
  


--
Lachlan Hunt
http://lachy.id.au/

**
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] Converting the heathen: never again

2006-02-27 Thread Lachlan Hunt

Lea de Groot wrote:

Maybe (s)he knew all those things were a problem


I doubt it.  If that were the case, I'm sure the response would have 
been more along the lines of: "Thank you, we are aware of these problems 
and we are investigating ways to fix them, but at this stage there is 
nothing we can do.  We apologise for the inconvenience."



and couldn't bear them being brought up by (cough, splutter) a *customer*


What kind of person would rather insult the customer instead of 
admitting they have a problem?


--
Lachlan Hunt
http://lachy.id.au/

**
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] Converting the heathen: never again

2006-02-26 Thread Lachlan Hunt

SunUp wrote:
When I could not find what I was looking for I was told: "I recommend 
that this issue in this case has not been a usability issue but 
instead has been a logic issue on the clients side, and I would 
recommend that you re-attend year 10-12 english classes in order to 
know this in future cases."


They obviously fail to understand the concept of usability.  It's not 
about their ability to use the site, it's about the user's ability, and 
the fact that they have chosen to completely disregard this usability 
issue is astounding.


When I complained about horizontal scrolling I was told: "I would 
recommend that you take a look around the real world, not just your 
own room and classroom, and see that these days even seniors are 
using the resolution of 1024x768.


They need to realise that screen resolution is irrelevant.  I suggest 
you inform them that it's the viewport size that matters, and even if a 
user has their screen resolution set to 1024x768 or higher, their 
browser window may not be much larger than 800px wide, either because 
they don't maximise it or they use a side bar or anything else that 
reduces the viewport size.


Personally, on my 1280x768 screen, my browser sits at around 900px wide. 
 When I used to use a 1024x768 screen on older machines, it would have 
been less than 800px, because I don't like maximised windows.


And you do have a choice, you have the choice of 
increasing your resolution, or alternatively to scrolls when you want 
to see anything to the left or down on the website.


How is that a choice?  In their case, that would be more of a 
requirement to effectively use their site!  Perhaps you should politely 
remind them of the meaning of the word "choice".


When I commented on the huge amount of javascript in the  I was 
told: "unobtrussive javascript does not work on a number of browsers 
short of the newest,...


That's a load of rubbish.  There are, of course, some features that 
won't work in older browsers, but that doesn't mean unobtrusive script 
cannot be written for them.



Javascript pulled from linked files doesn't work in some browsers?


I don't think either of you fully grasp the concept of unobtrusive 
javascript.  It is not merely script which has been externally linked, 
it is one that exhibits no obtrusive behaviours and degrades gracefully 
when not fully supported or not supported at all.  It is, in fact, 
entirely possible to have unobtrusive javascript that is contained 
wholly within the document, rather than an external file, although an 
external file is considered to be best practice.


As for the CSS that was in the  (body 
{margin-left:0px;margin-top:0px;margin-right:0px;margin-bottom:0px): 
... ".. could not be solved with a simple 
margin:0 as you have stated, which is only the newest standard in 
relation to this issue,


I would like to know where they got this information from.  The 'margin' 
shorthand property has been around for as long as the individual 
properties have been.  They all exist as part of CSS 1 and have been 
reasonably well implemented in browsers.  Although there are many box 
model related bugs, AFAIK none of them relate to the use of 'margin' 
instead of 'margin-top', ' -right', ' -bottom' or ' -left'.


but which does not resolve the issue in the 
browsers that this code is targetted at.


Ask them to name the browsers that they believe the 'margin' shorthand 
property (or, indeed, any other feature they claim can't be used) will 
not work in.


As to validation: "the W3C are self-appointed, and the standards they 
impose are self-regulated and are only recommended standards.


While that is technically true and there are some cases where the W3C 
recommendations don't reflect the interoperable behaviour found in most 
browsers, their standards need to be followed as closely as possible to 
achieve maximum interoperability.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Positioning a graphic

2006-02-26 Thread Lachlan Hunt

Angus at InfoForce Services wrote:
I appologize if this is off topic. The validator does not like "float: 
center;".


That's because the value is undefined for the 'float' property.

 What is the correct way to center an image? IE6 shows a 
centered Scottish flag which I would like and Firefox 1.5 does not.


IE is wrong.  There are various ways to center a box.  You can set 
'text-align' on the parent element, which will center all content.


p { text-align: center; }
/* where the img is a child of this element, just use an appropriate 
selector */


The other way is to use auto for left and right margin.

img { display: block; margin: 0 auto; )

IE 5.x doesn't support this method, but that shouldn't matter since it's 
obsolete anyway.  You can just let it degrade gracefully in it.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Page veiwing

2006-02-23 Thread Lachlan Hunt

SunUp wrote:

Woah!  They're such low resolutions, do you only have a 15" monitor?


Gee you guys ... not everyone has the latest 'n greatest in equipment.


I think everyone is aware of that, it was a simple question that was not 
meant to cause offence or otherwise insult or ridicule the person for 
failing to upgrade their equipment to support a minimum resolution of 
3840×2400 or higher. :-)



My work (government) PC has a 17" mon, 800x600 (because I LIKE this
res,


Interesting.

and I wish I had a dollar for every site I have to horizontal 
scroll on).


Indeed.  Sites that require horizontal scrollbars for 800x600 screens 
need to be fixed.  Their designers often fail to realise that not 
everyone has their browser windows maximised, so even if the user does 
have a slightly higher resolution, their viewport may still be 
relatively narrow.



I will have to be dragged kicking and screaming to 1024x768


Are you aware of the ergonomic considerations for screen sizes and 
resolutions?  I believe the recommended resolution for a 17" (4:3) 
monitor is 1280x1024 (that's even the native resolution of most LCD 
screens of that size) and 1024x768 for 15".


(For 17" LCD screens, that happens to work out nicely as 96 pixels per 
inch, making 1 device pixel equal the size of the reference pixel in 
CSS.  Not exactly sure about 15" screens, I haven't done the 
calculations, but I think it works out to be fairly close)


Regardless of that, I've never heard anyone so strongly object to the 
notion of using a higher screen resolution.  If you don't mind me 
asking, what are your reasons for making this decision?



I will certainly never go higher.


I wouldn't say never, I expect that the minimum resolution of newer 
operating systems to increase from 800x600 to 1024x768 in the near 
future.  It already went from 640x480 to 800x600 with WinXP (at least on 
devices that support it).


--
Lachlan Hunt
http://lachy.id.au/

**
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] "What is ..." XHTML Questions

2006-02-23 Thread Lachlan Hunt

Kat wrote:
I had written a huge email with a ton of questions, that I realised many 
really boiled down to one:


How did that one guy, 'beandizzy', pass all three tests?
http://www.goer.org/Journal/2003/Apr/index.html#results

How do I replicate those efforts?


1. The Simple Validation Test

  Validate your home page, fix every single errors and preferably fix
  all warnings, unless you have a very good reason not too.

2. The Laziness Test

  Validate all sub pages.

3. The MIME-type Test

  For all XHTML documents, the server must send the following HTTP
  header:
  Content-Type: application/xhtml+xml

The first 2 are easy.  Just run them through http://validator.w3.org/ 
and fix what it tells you to.  Although, you should be aware that the 
W3C validator has some XML limitations mostly related to 
well-formedness, but these will be picked up when you set the MIME type 
properly.


The third requires that you configure your server properly, and this 
depends on the server and/or the server side technology you're using. 
For static XHTML files using Apache, you can use a .htaccess file.  Just 
create one and add the following line:


AddType application/xhtml+xml .xhtml

You can use whatever file extension you like, though if your server 
needs to serve both HTML and XHTML documents, it will need to be 
different from the one used for text/html (usually .htm or .html).


1.What is the difference between the doctype and the standard namespace? 
What does this namespace provide: 'html 
xmlns="http://www.w3.org/1999/xhtml"; xml:lan="en" ' that isn't provided 
by the doctype?


The DOCTYPE (short for Document Type Declaration) refers to a DTD 
(Document Type Definition) which describes the legal structure of the 
document, including element content models, attributes and their types, 
and their default values.


The namespace is used to associate an element with it's defined 
semantics.  Elements in the XHTML namespace 
<http://www.w3.org/1999/xhtml> have their semantics defined in the XHTML 
recommendation or a related module.  The DOCTYPE does not define 
semantics at all, only structure.


Although, you should be aware that the XHTML 1.x DOCTYPEs define the 
default value for the xmlns attribute, and so a validating parser will 
not inform you that you have left it out.  However, it is required 
because not all parsers are validating parsers (no browser uses a 
validating parser) and so, they would not be aware that the elements 
were in the XHTML namespace.


2.>blockquotehowever XHTML document authors are strongly encouraged to use XML 
declarations in all their documents. Such a declaration is required when 
the character encoding of the document is other than the default UTF-8 
or UTF-16 and no encoding was determined by a higher-level 
protocol.>/blockquote<

http://www.w3.org/TR/xhtml1/

Is the XML declaration the XML prolog: ?xml version="1.0" 
encoding="UTF-8" ?


Yes, that is the XML Declaration, but the XML Declaration is not the 
same as the prolog, it is only part of it.


So if your character encoding is UTF-8, thus it is OK not to have this 
XML prolog?


Yes.

Or should that last 'and' have been an 'or' in the specs: 
Such a declaration is required when the character encoding of the 
document is other than the default UTF-8 or UTF-16 *OR* no encoding was 
determined by a higher-level protocol ?


According to the XML Recommendation, that is correct.


Thus if the server sends the character encoding as UTF-8,
then this prolog is not needed?


If the server sends any character encoding, the XML declaration is not 
required.  However, it is strongly advised that it be included when the 
encoding is not UTF-8 or UTF-16, because the file itself could be saved 
to the local file system, where no such protocol information exists, 
which may then make the document non-conforming.  (Note: The only 
exception to this rule is if you only use the US-ASCII subset of any 
encoding, which is also a subset of UTF-8)


--
Lachlan Hunt
http://lachy.id.au/

**
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] Google pages and the XHTML doctype

2006-02-23 Thread Lachlan Hunt

Christian Montoya wrote:
I just published a page with the new "Google pages" service and I 
would like to share it with you all:


http://sirokai.googlepages.com/home

If you do a view source you will see some pretty bad markup. An XHTML 
1.0 Strict doctype with invalid nesting and font tags.


This is, unfortunately, fairly typical of most pages with XHTML DOCTYPEs 
on the web.


I think this won't be good for XHTML if everyone is publishing pages 
through Google's service with the doctype and bad markup.


The problems certainly aren't limited to Google's service.  Just take a 
look at Geocities or any other major free web page hosting company like 
that.


I sent them a request asking them not to use the XHTML doctype, mentioning that 
the HTML 4.1 doctype is safer,


That's HTML 4.01.  Although, validation clearly isn't one of their 
goals, so they'd be better off just using .  It triggers 
standards mode, and since validation isn't a concern, there's no point 
lying about it.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Strange empty XHTML element issues in IE & FF

2006-02-22 Thread Lachlan Hunt

Vlad Alexander (XStandard) wrote:

Lachlan wrote:
It is just as easy to set , output an 
HTML4 DOCTYPE and not worry about inserting a space before '/>' for 
empty elements.


If you use the 10 lines of re-usable code that I suggested in your
XSLT, one does not need to "worry" - you have XML in and you have XML
out.


That code your referring too seems to be incomplete.  It doesn't handle 
every empty element, and in fact seems to explicitly filter out link and 
meta elements, along with script and iframe elements which makes no 
sense to me.


Excerpt from the XSLT:


  
  


Why do that?  AFAICT, this prevents those elements from being output. 
There may be a reason for that in your specific application, but it 
doesn't really make this code reusable as is, without modification.




  


That list is missing the following empty elements:
* 
* 
* 
* 
* 
* 
* 
* 

As a result, I believe (with the exception of link and meta) these will 
be processed as non-empty elements by your code, and thus not comply 
with Appendix C.



If you're using XSLT, why bother attempting to comply...


It depends on your requirements - right?


Yes, it does.


If you are doing a batch process and you plan to store the output
before serving it, you would want to store it in a parsable form that 
can be served as is or further processed by other XML technologies.


Fair enough, but do you agree that if there is no intention of any 
further XML processing, then converting to HTML 4 would be the most 
appropriate choice?


Can I assume that you agree that XHTML 1.0 was designed to be 
backwards compatible to HTML 4 if written to compatibility 
guidelines?


It is clear that that was certainly the intention, but I don't agree 
that the HTMLWG were entirely successful in doing so.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Page veiwing

2006-02-22 Thread Lachlan Hunt

Angus at InfoForce Services wrote:
I am sorry if this is off topic. I do not know who to ask. I have my 
screen resolution to default to 800 by 600 and thinking of changeing to 
1024 by 768


Woah!  They're such low resolutions, do you only have a 15" monitor?

I still would like to view my web pages in 800 by 600. 
I really do not have the knowledge to have the screendefault to 1024 by 
768 and still veiew web pages in 800 by 600.


Get yourself a copy of the Web Developer toolbars for Firefox [1] and IE 
[2].  They have options to resize the browser window to 800x600.  Other 
browsers may have similar tools available or may even be built in, but 
even if they don't, you can always resize them manually.


There's no need to change the resolution of your screen down to 800x600, 
since it's the viewport size that matters.  Also, keep in mind that not 
all users have their browser window maximised.


[1] http://chrispederick.com/work/webdeveloper/
[2] 
http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en


--
Lachlan Hunt
http://lachy.id.au/

**
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] :before and :after for code tag

2006-02-22 Thread Lachlan Hunt

T. R. Valentine wrote:

On 22/02/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

code:before {
 content: " 

No version of Internet Exploder will generate content. Unfortunately.


Not natively, but Dean Edwards' IE7 script will add limited support for it.

--
Lachlan Hunt
http://lachy.id.au/
**
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] Plain text v HTML on this list

2006-02-22 Thread Lachlan Hunt

Terrence Wood wrote:


On 22 Feb 2006, at 2:50 PM, Lachlan Hunt wrote:


Outlook users should ...switch to a better mail client that isn't broken.


Outllok can be configured to send plain text can't it?


It can, but there are a variety of serious problems with Outlook that 
make it an extremely bad program to use.  I won't go into much detail, 
because it's off topic, these are just a few issues.


* Lack of support for format=flowed [RFC 2646]
* Failure to quote properly by default, even in plain text mode.
  (Incorrect use of vertical bar '|', instead of '>' - not sure
  if that's by default, but it does do it.)
* Lack of support for sending the proper sig separator: "-- "
  (the space on the end would be stripped before sending,
   even if you typed it manually)
* Failure to remove the signature when replying to e-mails that
  do use the proper sig separator.
* Country specific prefixes to subject for replying and forwarding.
* Incorrectly formatted (bloated) attribution line.
* Signature is placed above the quote in replies by default
  (i.e. top-posting).

And that's just for plain text.  It gets worse when you look at its HTML 
mail.


Some of these things are fixed by using Quote Fix; but IMHO, you're just 
beating a dead horse.  It doesn't fix the major security holes in it, 
its inferior junk mail filter, its bloated user interface, and probably 
many more issues I can't recall off the top of my head.


Now, this is getting way off-topic so if anyone wants to continue the 
discussion with me, I'll be more than happy to respond off-list.


I usually don't bother to read the 1mm tall text it sends out 
(screenshots on request), unless I'm really interested in the thread.


Can you put the screenshots up somewhere and link to them?  I've never 
seen such small text, either in or from Outlook.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Strange empty XHTML element issues in IE & FF

2006-02-21 Thread Lachlan Hunt

Vlad Alexander (XStandard) wrote:
You can write your XSLT to output XHTML that follows compatibility 
guidelines. You can use the technique in this XSLT:


http://misc.xstandard.com/wsg/preview.zip

If you need a hand with your XSLT, contact me off the list and I'll 
be happy to help.


If you're using XSLT, why bother attempting to comply with the oft 
criticised, self-contradictory, *non-normative* "Appendix C"?  (I will 
not get into another flame war over this, I just want to know your 
reasons, assuming you actually have any.)


It is just as easy to set , output an HTML4 
DOCTYPE and not worry about inserting a space before '/>' for empty 
elements.  There is no benefit to be gained from serving XHTML as 
text/html to the client, even if there are benefits gained from working 
with XHTML on the server side.


--
Lachlan Hunt
http://lachy.id.au/

**
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] Plain text v HTML on this list

2006-02-21 Thread Lachlan Hunt

Nick Gleitzman wrote:
A frequent request, which occasionally needs to be remade: could list 
members please use plain text for posting?


Yes, absolutely!  The following articles discuss the various issues 
further.  Although they generally relate to USENET, most of the advice 
applies equally to mailing lists like this as well.


http://www.cs.tut.fi/~jkorpela/usenet/dont.html

This is some of the reasons why HTML mail is not appreciated:
http://www.georgedillon.com/web/html_email_is_evil.shtml

And also, people need to learn how to quote properly:
http://www.netmeister.org/news/learn2quote.html
http://www.xs4all.nl/%7ewijnands/nnq/nquote.html

Note: Outlook users should get Quote Fix or switch to a better mail 
client that isn't broken.


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-02-21 Thread Lachlan Hunt

Ted Drake wrote:

Hi all you former table hackers out there. I've got a simple question.

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; }

--
Lachlan Hunt
http://lachy.id.au/

**
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] Strange empty XHTML element issues in IE & FF

2006-02-21 Thread Lachlan Hunt

Paul Hempsall wrote:

I came across a strange issue last night while converting some XML data
via an XSL template into XHTML.
 
Issue 1: In the Head section of my XHTML I had an empty script element

(see below). IE refused to load the page.


IE does not support XHTML at all.

All of your problems are a result of using the wrong MIME type.  XHTML 
should not be served as text/html, it should be served as 
application/xhtml+xml or other XML MIME type.


When you serve XHTML as text/html, browsers think they are receiving 
HTML, so that's how they parse it.  They have to resort to error 
handling techniques to handle all those extra slashes and, in this case, 
missing end tags.


The following explanations of your problems only relate to text/html 
documents.  The syntax is perfectly well-formed XML, but requires an XML 
MIME type to be parsed properly.



 FF had no problem with this.
 



The reason Firefox appears to have no problem with it is because of the 
way it will reparse the entire document from that erroneous script 
element when it hits EOF and has not found a matching  end-tag. 
 This behaviour cannot be relied upon, or any other markup that 
currently causes Firefox to reparse it, as this will likely change in 
the not-too-distant-future.  As far as browsers are concerned, that is 
exactly equivalent to:




</pre><tt>If you remove the '/' from your document, you will get exactly the same 
</tt><tt>result.
</tt><pre style="margin: 0em;">

Compare these:
<a  rel="nofollow" href="http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo">http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo</a>
<a  rel="nofollow" href="http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript/%3E%0A%3Cp%3Efoo">http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript/%3E%0A%3Cp%3Efoo</a>
<a  rel="nofollow" href="http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo%0A%3Cscript%3E%3C/script%3E">http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo%0A%3Cscript%3E%3C/script%3E</a>

</pre><blockquote style="border-left: #EE solid 0.2em; margin: 0em; padding-left: 0.85em"><pre style="margin: 0em;">
To get IE past this line in the markup I had to change the text to read:
</pre><tt> 
</tt><tt><script type="text/javascript" src="nav.js">


That is the correct what to handle it.


Issue 2: In the body of my document I have an empty . IE rendered
the page correctly. FF didn't close the element, so my CSS didn't get
implemented correctly.
 



Again, that is exactly equivalent to: , with no end-tag.

See what the DOM looks like:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cdiv/%3E%0A%3Cp%3Efoo


To allow FF to process the div, I had to modify the line to:
 



That is correct.


I thought I might need to add a space before the forward slash (ie. ), but this didn't make any difference.


The space is required for compatibility with some older browsers 
(Netscape 4.x I think), so that they don't completely choke on it.



What's also weird is that I have plenty of other self-closing elements
in the document, but these didn't break the browsers.


It's ok to do it with empty elements like , , , 
etc. because they're already EMPTY in HTML and don't require end tags. 
In such cases, the '/' is just handled as part of error recovery, the 
browser doesn't keep looking for an associated end tag.  The same is not 
true for elements that aren't EMPTY in HTML.


--
Lachlan Hunt
http://lachy.id.au/

**
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] A legitimate case for pop-ups

2006-02-21 Thread Lachlan Hunt

Patrick H. Lauke wrote:

Lachlan Hunt wrote:
No, that just demonstrates how ignorant judges can be with regard to 
technical implementations.  The article states:


Off topic, but it made me smile thinking about my not so clued up higher 
management going on about adding a "GIF" to pages to mean "image". If 
only they knew that I'm disobeying their wishes and sometimes use a JPEG 
or even PNG instead...


I know how you feel, I get requested to use all sorts of inferior 
technology in various jobs.


At a previous job, I worked with a graphic designer that didn't know 
much about PNG at all, and actually once requested that I change all the 
PNGs to GIFs.  I informed her that PNG was superior to GIF in every way, 
and that I only had to avoid alpha transparency and it works just fine.


I don't even use GIF any more, especially since PNG8 can do index 
transparency just as effectively as GIF, and I rarely use animated GIFs.


--
Lachlan Hunt
http://lachy.id.au/

**
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] A legitimate case for pop-ups

2006-02-20 Thread Lachlan Hunt

Kat wrote:
I never thought the day would come when there actually was a legitimate 
use for pop-ups!


I'm still waiting for that day.

It's legitimate to use pop-ups, if a court judge orders you to :) 
http://australianit.news.com.au/articles/0,7204,18214048%5E15306%5E%5Enbv%5E,00.html 


No, that just demonstrates how ignorant judges can be with regard to 
technical implementations.  The article states:


| Justice Wilcox ordered Sharman to use pop-up windows to force users to
| upgrade their Kazaa systems to a new version that would include a
| copyright filter.

Assuming The Australian actually quoted that correctly, and didn't mean 
that:

a) they were ordered to force users to upgrade in some way. and
b) they decided for themselves to use popups for that purpose.

Then this just proves that upper-level management (a judge in this case) 
should not ignorantly force specific implementation details upon those 
doing the actual implementation.  There may be other ways to force 
upgrading without using a popup and the actual implementation is 
irrelevant from a legal point of view, as long as the end result is the 
same.


--
Lachlan Hunt
http://lachy.id.au/

**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**



Re: [WSG] Font Sizes - Best practice

2006-02-20 Thread Lachlan Hunt

russ - maxdesign wrote:
people that use the Internet world wide.  Consider this: the number 
of people that visit my relatively small site every single day 
would be more people than I've met in my entire life time, so it's 
hardly...


This could be read in two ways. You have a hugely popular site, or 
you need to get out more. I am hoping for your sake it it the former 
;)


I hadn't thought of it that way. :-)

... It's ok for relatively unimportant legal mumbo jumbo (copyright 
notices, disclaimers, etc.) to go smaller than that, but not for 
main content.


Could it not be argued that the "unimportant" legal content is 
sometimes more important to some users than the general content on 
the page?  :)


I'm sure there are some that think such notices should be shown in large 
bold letters, read and agreed to by every user prior to getting access 
to the rest of the site.  They do exactly that on DVDs and Videos, often 
on porn sites where the user must agree to being over 18, etc.  But from 
the average user's perspective, it's the main content that's most important.


--
Lachlan Hunt
http://lachy.id.au/

**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**



Re: [WSG] Font Sizes - Best practice

2006-02-20 Thread Lachlan Hunt

Martin Heiden wrote:
I read a lot of threads about font-sizing lately, but I still did 
not catch the point of best practice yet.


I use to set the body font-size to 62.5% for getting 1em = 10px at 
default settings.


Eek!  Never rely on default settings, many users will change them.

So if a user sets another preferred font-size, my hole layout will 
adjust to that value,


Good.

On the other hand, I don't know anyone who changed the default 
font-size in his/her browser


I do, but that's irrelevant.  The number of people you know, or anyone 
else knows for that matter, is insignificant compared with the number of 
people that use the Internet world wide.  Consider this: the number of 
people that visit my relatively small site every single day would be 
more people than I've met in my entire life time, so it's hardly 
surprising that the people you know wouldn't even come close to being a 
good representative cross-section of the wider population.



but lot's of people (mostly designers) who prefer smaller font-sizes.


It's unfortunate that so many designers prefer small font sizes.  They 
fail to realise that while they may think small fonts may look good from 
a design perspective and are easily readable on their massive, 
super-high resolution, 21" monitors, it actually looks really awful and 
is extremely difficult for many users to read.


Not every user will understand how to increase the font size, let alone 
know how to configure a minimum size in their browser.  Those that do 
know will be able to work around such bad author decisions, but those 
that don't will be left squinting at their screen, which is bad for 
ergonomics, usability and accessibility.


IMHO, any smaller than 'small' (approx 82%) is too small for main body 
copy, though I know some that argue font sizes generally shouldn't be 
smaller than 'medium' (100%).  It's ok for relatively unimportant legal 
mumbo jumbo (copyright notices, disclaimers, etc.) to go smaller than 
that, but not for main content.



Well, the question is: Which group of people is more important?


I'm hoping that's a rhetorical question!  The users are more important. 
 They're the ones visiting your site trying to read it and if they 
can't read it, they'll leave.



Or better: Is there a way to please both groups?


Yes.  Don't use small fonts.  Those that can't read small fonts will be 
happier with the larger fonts, those that can read small fonts will have 
no difficulty reading the larger font and if they find it too big, they 
can either decrease it or even just sit a little further back from their 
screen.  You need to build for the lowest common denominator (within 
reason), and when it comes to font sizes, it's better to be slightly too 
big for some, than too small for others.


--
Lachlan Hunt
http://lachy.id.au/

**
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] problem with Conditional Comments

2006-02-20 Thread Lachlan Hunt

Soeren Mordhorst wrote:




This one should link to a CSS file for IE6, not IE5.x, but I'll assume 
that was just a typo and you meant something like ie6xstyles.css.



So what I need are three css-files:
- normal layout.css
- one css-file for IE 6
- one css-file for IE lesser than 6 (5.0 - 5.x)

Any suggestions?


Besides the mistake above, I don't see what else you could be having 
trouble with.  That's exactly what you need to do if you wish to support 
IE5 and IE6 in this way.


In future, always provide a URI to a test page demonstrating the 
problem, you'll be more likely to get much more helpful response if you do.


--
Lachlan Hunt
http://lachy.id.au/

**
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] occam's razor again

2006-02-16 Thread Lachlan Hunt

Designer wrote:

Back button? I'd like to bet that >75% of users don't know what that is!


Aw, people can come up with statistics to prove anything.  Forfty 
percent of all people know that.


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-02-15 Thread Lachlan Hunt

Herrod, Lisa wrote:

Lachlan Hunt wrote:

The users!  Please, won't somebody think of the *users*!


This line reminds me of something from my favourite show when I was a kid:
Fantasy Island. "the plane, the plane!" :)


Actually, it's a slightly misquoted line from Helen Lovejoy in the The 
Simpsons: "Won't somebody _please_ think of the children??"


Every site is different, every user is different, every demographic varies 
from the last.

...
Don't assume anything... whether or not it's best practice.


Which is exactly why I make no assumptions about the user's browsing 
environment or preferences, and I don't attempt to force new windows 
upon them which they may or may not want - they are free to do as they 
please, without interference.


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-02-15 Thread Lachlan Hunt

Jude Robinson wrote:

Lachlan Hunt wrote:


There are no valid use-cases or reasons for opening a popup window


Well...there's *one*: http://www.useit.com/alertbox/open_new_windows.html


No, Jakob is wrong about that one.  I know, it's strage, he's rarely 
wrong about usability issues, but he is in this case.


Browsers and/PDF viewers can be configured in various ways:
* Open PDF within browser (the unfortunate default)
* Save PDF to disk, then open in external application (e.g. "PDF 
Download", Firefox extension)

* Load PDF in external application (saving only to temp directory)
* User may not have a PDF plugin installed, and just be prompted to save it.

For anyone without the default setting, forcing a popup window would 
result in new blank window.  For those with the default setting, I'm 
aware of the fact that this has been known to cause problems in older 
versions (incl. crashing), but that is an issue for the browser/PDF 
plugin vendors to address, not each individual site author.


The only information a browser needs is this in the HTTP headers:
  Content-Type: application/pdf

It may help to include that in the type attribute.
  foo (PDF)

But few browsers ever use that attribute by default.  There may be 
extensions that do (I don't know), but CSS can be used to style it or 
JavaScript to do something else with the link to make it obvious to the 
user that the link is to a PDF.


Theoretically, it's possible to interpret that type attribute to mean 
open a new window, and it would seem trivial to write a Firefox 
extension (or Greasemonkey script) to do that.


The important point is that telling the user/browser that the file is a 
PDF should be all that is required for the user/browser to make an 
informed decision about what to do with it.


--
Lachlan Hunt
http://lachy.id.au/

**
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

2006-02-15 Thread Lachlan Hunt

Serdar Kılıç wrote:
When I first started my weblog all internal links had no target 
attribute thereby browsing within my site was within a single window. 
Any offsite links were brought up in a new window, a window for each 
link clicked.


The way *I* browse some sites is how I built my site.


But you need to remember that you're not building your site for you. 
You're building it for *your visitors*.  For every user, there is only 
one person can decide if they want a new window: themselves!


The problem is is that there are no visual clues whether or not a 
link will open in that window or a new one (I'm not a fan of little icons).


Which is why shouldn't rely on a author to a) open a window for you if 
you want one, or b) not open a window if you don't want one.  You can 
use a user stylesheet to indicate the presence of a target attribute:


a[target] { cursor: crosshair; }

But I think the best option is to completely disable the target 
attribute to prevent the author from interfering with your decision and 
make it yourself, every single time.  You cannot possibly rely on the 
author to make the right decision for you, because every user is different.


--
Lachlan Hunt
http://lachy.id.au/


**
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

2006-02-15 Thread Lachlan Hunt

Kevin Futter wrote:

On 15/2/06 6:57 PM, "Lachlan Hunt" <[EMAIL PROTECTED]> wrote:
Many users hate popup windows.  There are no valid use-cases or reasons 
for opening a popup window, don't do it.  If you think you have one, I'd 
like to hear it, but know this: I've heard many excuses over the years 
(some more often than others) but every single one of them has been 
flawed in some way.


Yes, in fact I do have one. For a couple of sites I do for musicians, I open 
a Flash-based music player in a new window - a small pop-up. Why? Because if 
you embed the music player in the page and begin to play a song, and then 
navigate to a different page or website, you lose the entire show.


I'm not convinced.  There is no reason why the user can't choose to open 
it in a new window/tab for themselves.  Even if they don't, they can 
continue navigating elsewhere in a different window/tab.  Besides, you 
shouldn't need to write your own flash-based music player.  You could 
provide the song in an downloadable MP3 or a streaming audio format and 
let them play it in their own media player.


--
Lachlan Hunt
http://lachy.id.au/


**
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

2006-02-15 Thread Lachlan Hunt

Jona Decker wrote:

Lachlan Hunt wrote:

For what reason are they annoying?  You can't just say something is
annoying because you think something else is better, you have explain
what it is about it that is annoying, and perhaps the issue could be
addressed to improve the method without resorting to popups.


If the viewport isn't the "right" size you do not see 
this expanded text. So you click on the help question mark, and
seemingly nothing happens. 


The only way I could replicate this in the demo page was by resizing my 
window so that the the text box and help button were at the bottom of 
the viewport with nothing visible below them.  It seems strange that you 
wouldn't have scrolled the page up nut even then, the scrollbar clearly 
resized when I clicked it, indicating that I need to scroll down.


I know it's not perfect, but it wouldn't be hard to solve this problem, 
here's a few quick ideas.  (I'm sure there's many other possibilities)

* A script could scroll the page a little (if required).
* The icon could change from a question mark to a down arrow, pointing 
to the help.

* The help could be positioned beside the field, rather than below.

--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-02-15 Thread Lachlan Hunt

Designer wrote:
I'm surprised at your comment that the number of windows is being 
reduced these days - have you seen Dreamweaver lately?


Dreamweaver has a nice tabbed interface, I'm not sure what you mean.

 Flash 7? 


No, I don't use flash.


Photoshop?


I find photoshop's use of windows annoying, it would help a lot if all 
the little tool windows would actually dock together in one manageable 
group.


I find it impossible to work on a lot of these graphics 
programs without two monitors on the go!


And you don't consider that evidence against the use of so many windows?

Incidentally, preview pane: surely, having something appear in the 
preview pane is the same as opening it?


Yes, it is.  But it doesn't appear in the preview pane until I select 
it, but even if I do, it is 100% safe for me.


And opening mail is a really 
good way to set a virus free.


I'm well aware that there are/have been major security holes in Outlook 
that allow malicious software to run simply by reading e-mail, but this 
is impossible to do in Thunderbird (or any other decent mail client, for 
that matter) in plain text mode, and I know of absolutely no security 
holes even in HTML mode, which I'm rarely in anyway.



Looking at the subject, who it's from etc and deciding whether to
read it or bin it is much more secure as far as I can see.


True, and the few that aren't picked up by my junk filter get manually 
marked as junk before I read them.  But even if I did open them, it 
would still be completely safe.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-02-15 Thread Lachlan Hunt
rs, I try 
to get some of this flexibility and uncluttered approach into my web


How could opening new windows be considered an "uncluttered approach"? 
Remember, one of the major benefits of tabbed-browsing is that it 
reduces the clutter of windows on the desktop.


pages. If I have a gallery of images, a click on a thumbnail will 
perhaps open a larger display of the image - in a new window.


Eek!  I hate galleries that do that.  Have you considered the 
possibility of a better alternative?


http://www.alistapart.com/articles/imagegallery/
http://www.huddletogether.com/projects/lightbox/

Lightbox looks better, has the same result of a popup, in that it 
doesn't navigate away from the current page, but it's easier to close by 
clicking anywhere, there's no need for clicking the close button.  It's 
currently got some keyboard navigation problems, but it could always be 
improved.


If a link is waiting for the content to be completed, an alert box "available 
shortly" pops up


I really don't understand how you think popping up an alert box that the 
user needs to dismiss before anything will continue is a usability 
benefit.  Browser developers realised a long time ago that alert boxes 
are useless and annoying.  This is why they are moving the much less 
obtrusive information bar approach.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-02-15 Thread Lachlan Hunt

Stephen Stagg wrote:

On 15 Feb 2006, at 12:28, Lachlan Hunt wrote:


What I really don't understand is that there are so many people who 
participate in this and various other mailing lists, newsgroups and 
forums that actively advise against using popups and explain why they 
hate them, yet you still somehow believe that users are ok with them. 
Newsflash: we are users too!  Listen to us when we tell you outright 
that *we hate popup windows!*  Do not use them, find a better solution.




For that matter, I am a user too and I like popups when used properly.  
Perhaps your aggressive responses tend to be a bit pony-ish?

You can never please everyone, the example you gave of


http://juicystudio.com/article/form-help-without-popups.html


is not something I prefer over a well implemented popup and therefore, 
for this issue, using these inline-hidden-help-comments are annoying me, 
and people like me.


For what reason are they annoying?  You can't just say something is 
annoying because you think something else is better, you have explain 
what it is about it that is annoying, and perhaps the issue could be 
addressed to improve the method without resorting to popups.


If you don't like having to move your mouse up to the toolbar of your 
window when closing them, learn your OSs key combination for closing the 
active window.  (Windows: Alt-F4, Mac OSx Cmd-W)  This way, you can 
improve your productivity.


I know the key combination, but then I'd have to move my hand to the 
keyboard which takes just as long.  While browsing I use the mouse far 
more often than the keyboard since a) most of the time, I'm not typing 
anything, and b) my mouse has every major browsing function built in 
(back/forward, clicking links (obviously), scrolling, selecting text, etc.).


I don't have a >100Mbit connection so I like it when a site opens an 
external link in a new window,


Then you have every right to request your browser to do so for you. 
What reason does the author have to believe that all users feel that way 
about the situation, when they clearly don't?


Every time I click a link, I make that decision for myself.  It's not 
that hard.  If I want the same window, I'll left click and if I want a 
new tab (or window, if you prefer), I'll middle click.  You and every 
other user can perform exactly the same function with your browser 
(using whatever mouse/keyboard command it's configured with), the author 
should not interfere with the user's decision.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-02-15 Thread Lachlan Hunt

James Gollan wrote:

Lachlan Hunt wrote:

Ian Anderson wrote:

Lachlan Hunt wrote:


I think generalisations like "users hate popup windows" are perhaps a 
little unhelpful.


But the statement is 100% accurate...


It may be technically 100% accurate, but in that case so is the 
statement "users hate it when a new site opens in the current window and 
takes them away from the site they were viewing". It only takes 2 users 
to make this true. And these 2 users may also be annoyed :)


True, but such users can only be annoyed with themselves for failing to 
understand how to use their browser in a way that gives the results they 
want; not with the author for failing to meet their specific 
requirements, which will very likely differ significantly between every 
user.


I am not a pop-up advocate, I think it's best to clearly identify 
external links but open them in the current window. I do, however, 
wonder about the number of users that actually know that they can 
override the browser and open a link in a new window.


I'm sure there are many that don't know how to open a new tab/window, 
but I'm sure there are many, many more that don't know how to prevent a 
new tab or window.  This is, perhaps, a browser usability issue, but it 
should be addressed by the browser vendors, not web page authors.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-02-15 Thread Lachlan Hunt

Ian Anderson wrote:

Lachlan Hunt wrote:

Many users hate popup windows.  There are no valid use-cases or 
reasons for opening a popup window, don't do it.


I disagree with this statement. In my opinion, there are several very 
good use cases.


Name one for which a popup window is the only valid and, indeed, best 
solution!


The primary one is help windows, where instructions can be compared with 
the items in the main window. A variant of this is T&Cs in forms, where 
there are serious consequences for the user if they move off the page 
while in the middle of completing a form - they may lose some or all data.


While that is legitimate use-case that comes up quite often on the web, 
the best solution does not involve popup windows.  In fact, related to 
the issues I discussed earlier, popup windows can be prevented and you 
have no idea which users do this.  Thus, while relying on the popup 
windows to solve this problem may work for 99% of visitors, for the 1% 
that don't get a new window (incl. those without script and those, like 
myself, that explicitly disable popups), the problem you're trying to 
solve is still a problem.


This is one solution that doesn't involve popups, that I have actually 
used myself in a recent project.

http://juicystudio.com/article/form-help-without-popups.html

That solution works acceptably for 100% of users, regardless of their 
support for javascript, popup windows or any other feature.


I think generalisations like "users hate popup windows" are perhaps a 
little unhelpful.


But the statement is 100% accurate.  I, as a user, hate popups.  I know 
of many others that hate popups too.  I did not say "all users", just 
"users".  Regardless of how many users that is, are you really willing 
to annoy them?  Is it not safer to avoid using popup windows, 
considering that people that don't mind them won't be at all upset when 
they don't see them; but those that hate them, will be if they do?


I am sure a lot of people dislike popup adverts, but 
to dismiss all use of popups on this basis is clearly to throw the baby 
out with the bath water.


I'm not just dismissing them on the basis that popup adverts annoy 
people, I'm dismissing them for serious usability and accessibility 
concerns, some of which I discussed earlier.  Here's another:


Every time you open an unrequested window (assuming my browser wasn't 
configured to block them completely), that's another window I eventually 
have to close.  That's annoying, especially when I didn't request it. 
My mouse has a built in back and forward button and when you open a 
popup, those buttons don't work - there is no "close popup" button.  It 
takes longer to move my mouse up to the close button than it does to 
push the back button with my thumb, which is just wasting my time on a 
tedious task I shouldn't have even been faced with.


That is absolutely no better than using the target attribute.  In 
fact, for accessibility reasons, it is worse.


This is not true,


Yes it is.  I even gave an example to explain why.  Just because your 
usability testing failed to test the scenario I presented, doesn't mean 
it doesn't happen.



Also, because the button UI is usually turned off,


You're assuming the browser is configured to let you turn off the 
chrome.  That's another bad assumption, because browsers can be easily 
configured to always show the chrome that the user wants.


there are fewer issues with users starting to surf in the new window 
and losing their window history, which is a problem using target _blank.


So what if they started to surf with the new window!?  Is there some 
rule against that?  It's a browser window, just like the original,  It 
clearly doesn't really matter whether they browse with that one or any 
other.


What I really don't understand is that there are so many people who 
participate in this and various other mailing lists, newsgroups and 
forums that actively advise against using popups and explain why they 
hate them, yet you still somehow believe that users are ok with them. 
Newsflash: we are users too!  Listen to us when we tell you outright 
that *we hate popup windows!*  Do not use them, find a better solution.


--
Lachlan Hunt
http://lachy.id.au/
**
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

2006-02-15 Thread Lachlan Hunt

Bert Doorn wrote:

Serdar Kýlýç wrote:

How does one open a new window with a 4.01 Strict DOCTYPE and have it
be valid? For my weblog I ran the w3 validator and it complained that
there is no attribute called target


The users!  Please, won't somebody think of the *users*!

Many users hate popup windows.  There are no valid use-cases or reasons 
for opening a popup window, don't do it.  If you think you have one, I'd 
like to hear it, but know this: I've heard many excuses over the years 
(some more often than others) but every single one of them has been 
flawed in some way.


The main idea is that one should not open new windows at all, leaving it 
up to the user to decide, which is why the target attribute was removed.


Correct.

But if you want to (or "have to"), either go back to transitional or use 
javascript.  You may find some discussions about it in the mail list 
archives, but the simplest implementation would go along these lines:


link text


That is absolutely no better than using the target attribute.  In fact, 
for accessibility reasons, it is worse.


Good browsers, like Firefox (and probably many others), allow the user 
to easily disable the effect of the target attribute when it would cause 
a new window to open, without interfering with legitimate uses of it in 
frames (which are also evil).  However, with window.open, the ability is 
not so easy.  It is possible to do in Firefox.  I do it myself, so that 
any call to window.open acts like a regular link and opens the page in 
the same window).  However, it does have side-affects that an average 
user would find more difficult to cope with.


Thus, while I personally find that both the target attribute or 
window.open() (when used like the example above) are of little concern 
[1], most users wouldn't be able to override the script as easily as the 
target attribute.  Additionally, a user stylesheet may be used to 
indicate the presence of the target attribute, but not of that specific 
type of script, and so the user has no opportunity to take further 
action to prevent it (if required).


Also, for those that don't know how to prevent even the target attribute 
from opening a new window, why should they be forced to accept them?  Do 
you consider it a kind of opt-in/out feature, whereby unless a user 
explicitly requests not to see new windows, then they must be ok with them?


[1] window.close(), on the other hand, is a pain in the *** thanks to a 
bug in Firefox, which has only recently been fixed in the trunk

--
Lachlan Hunt
http://lachy.id.au/
**
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 6 Problem] -Container will not align centre to the page.

2006-02-13 Thread Lachlan Hunt

Omen King wrote:

I have gone about creating this site for a class I have.
I have been using in the past XHTML 1.0 strict but the doctype we must use 
is XHTML 1.1 Strict and it is giving me trouble.


Firstly, XHTML 1.1 Strict doesn't exist, it's just XHTML 1.1.  Don't 
confuse it with XHTML 1.0 Strict/Transitional/Frameset, there are no 
such variants for XHTML 1.1.  Secondly, is your teacher aware of the 
fact that real world browsers don't support XHTML 1.1 properly, and that 
some don't support it at all?  Most notably, no version of IE supports 
it - anyone who says (or tries to show) otherwise is lying.  Perhaps my 
recent article would be an enlightening read for both you and your teacher.


http://lachy.id.au/log/2005/12/xhtml-beginners


I have already know the problem is some kind of rule issue. I am researching
the problem currently but if anyone already knows the anwser it would be
greatly appericated.

Please view this page both in IE 6 and Firefox.

http://www.monsterboxproductions.com/hwk/thedigitallibary/index.html


It appears to work in Firefox, IE7 and Opera just fine (though, it 
really only "works" in IE thinks it's receiving HTML, not XHTML - it's a 
MIME type issue).  I don't have IE6 available to test in without 
uninstalling IE7.  However, you need to be aware that using the XML 
declaration triggers quirks mode in IE6 (they fixed that bug in IE7) and 
this may be the cause of your immediate problem.


Remove this line:  


To fix any other problems correctly, it requires using the correct MIME 
type.  The easiest way is to change the file extension to .xht or .xhtml 
and add this line to your .htaccess file on your server (create it if 
you don't have one, Google for ".htaccess files" for more info)


AddType application/xhtml+xml .xht .xhtml

(After doing this, you won't be able to view it in IE, only Firefox, 
Opera and other descent modern browsers, but you will learn a valuable 
lesson none-the-less)


--
Lachlan Hunt
http://lachy.id.au/

**
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 sued over non-accessible site

2006-02-11 Thread Lachlan Hunt

Nic wrote:

At which point does one's right to "do as one chooses" start stepping on
another one's right to access services?  Would we even *have* this
discussion if people being refused access to websites were black and the
refusal was because they are black?


I really don't see the point you are trying to make here.  There is no 
difference between refusing access to someone based on physical/mental 
disability (those that require assistive technology) and someone based 
on their race, culture, religion, etc.  It's unnecessary discrimination 
either way.


--
Lachlan Hunt
http://lachy.id.au/


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**



  1   2   3   >