Re: [WSG] Tag clouds

2006-03-14 Thread Ben Ward
On 3/14/06, James Ellis <[EMAIL PROTECTED]> wrote:
> I've often wondered why these so-called tag clouds don't use  and
>  tags (maybe they do ?)
>
> they are inline tags. they convey meaning : 2 bigs is more important
> than 1 big etc.
>
The problem there is that  and  tags _don't_ mean
anything. They're semantically void just like  or .
They're purely presentational [1]

On 3/14/06, Ben Buchanan <[EMAIL PROTECTED]> wrote:
> Technorati's multiple-emphasis method is interesting, but I'm not sure
> if the semantics are entirely sound (can you really just keep adding
> more emphasis?). Given that current user agents don't really do
> anything with the tag combinations you are ultimately left with a
> visual-only cue to importance.
>
I don't see why you _can't_ nest them, but it is unspecified
behaviour. What do you mean by 'User Agents doing something with the
tag combinations'? Is there anything you want a UA to do that isn't
visual or aural that can't be described in a stylesheet?

I'd be inclined to either nest em and strong phrase elements, or to
group the tag importance into just three levels for markup, and add
additional granularity via classes.

So:
* Normal Importance: , , 
* Higher Importance: , , 
* Highest Important: , , 

As such, with raw HTML you're describing three different levels of
importance, and with CSS you can enhance that extra levels as required
with classes. Ultimately, so long as the mark-up is in some way
logical then you've probably already achieved 'optimal' mark-up within
the limitations of HTML.

Ben

[1] http://www.w3.org/TR/html4/present/graphics.html#h-15.2.1


Re: [WSG] Google and HTML5

2006-01-28 Thread Ben Ward
On 1/26/06, Miika Mäkinen <[EMAIL PROTECTED]> wrote:
> Christian, that was my point...  atleast *sounds* presentational
> (thought it could indicate text that is "less important") and that was why I
> wasn't happy to see it's included in HTML5...
> http://whatwg.org/specs/web-apps/current-work/#the-small
>
Perhaps re-read the description of  in the WebApps spec. The
point is that they've specified a meaning for it. In 'HTML5' (or
whatever it eventually gets called),  means something and is
differentiable from other text in the page.

 may sound presentational because that's what it is in HTML4.
But in HTML5 it refers to 'the small print' of a document, which is an
entirely different use of text from a standard paragraph.

What the WHATWG are doing which I think is clever, is they're reusing
existing, meaningless presentational elements where they can. If I
remember correctly,  has been re-specified too.

As for the new elements: ,  and so forth: It's all
about separating _documents_ into component parts. There's nothing
presentational about them: You have headers on letters, official
documents and all sorts, thus there's now an element to identify that
section of a document. Same for a footer.

Consider the detail in which you can describe computer code in HTML:
, , , … huge descriptive power for technical
publishing. But there's nothing like the same level of detail
available non-technical documents.

Most of these new HTML5 elements are designed to make HTML a richer
language for the things the web is used for: Namely publishing
documents within the frame of a larger website.  allows you
to identify the primary page content from the site 'frame'. Useful for
print stylesheets and generic richness, *very* useful for search
engines (it means that you can avoid indexing unrelated content like
advertising and navigation).

Lots of examples. Could go on for hours, but this is probably plenty
long enough!

G'night,

Ben


Re: [WSG] Lengthy form buttons

2005-12-07 Thread Ben Ward
On 08/12/05, Tim Burgan <[EMAIL PROTECTED]> wrote:
> Does anyone have a clue as to why this happens:
>
*I think* it's something to do with a different implementation of XP
Visual Styles in Trident, but I don't know what the specific problem
is (it could be as little as being a bug in the IE themes
implementation that they just didn't fix, really).

As far as I know IE uses a different interface to get the themed
buttons than that of other Windows applications (note that the buttons
are themed fine in Firefox and scale pretty well).

The only way I can think to get around it would be to style the
buttons with CSS, but you'll have to sacrifice the native look.

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Standards and .NET

2005-11-08 Thread Ben Ward
A few tips based on my experience of working with ASP.NET 1.1:

* First up, consider sticking to an HTML 4 DOCTYPE. It's really not as
big a deal as some advocates would have you think ;-) - Critically, if
you try and force it to use XHTML and someone accidentally clicks
'Design View' your code is ruined. VS2003 works in HTML, you'll have
an easier path if you do too. As has been said, .NET 2 and Visual
Studio 2005 introduces XHTML support, you really need to upgrade your
development tools if you want to work with it.

* Avoid using the pre-wrapped ASP.NET controls. DataGrids aren't so
bad, but you get much more mark-up control by using a Repeater.
Similarly, rather than using an asp:label, there's a mark-upless
version that doesn't insert  elements. I forget the name, sorry,
but it does exist.

* Don't use postback. Just give up, it's a badly implemented hack to
maintain state in a webpage misusing forms and introducing complete
JavaScript dependence. Just because Visual Studio makes it very easy
to accidentally use it, doesn't make it ok. Just pretend it was never
there.

Also remember that you don't have to recompile when you make changes
to an aspx file (only recompile for codebehind changes). It's probably
insulting to be told that for some people, but when I started working
with .NET last year I spent months not really understanding how the
whole aspx thing worked in relation to compilation.
Anyway, knock on effect is that once you've got something producing
stable data, you can edit the page layout CSS and aspx components
without recompiling, from any editor(s) you like and preview in
whichever browsers you like. That's a huge help.

I think that ultimately, it's all a case of learning to quirks of a
very complex system. Once you trim off the cruft though, there's not
much to go wrong!

Good luck,

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Affecting width of scrollbar in FF

2005-10-20 Thread Ben Ward
> On firefox default theme under WinXP (XP-Style) the scrollbar width is
> 19px (there's a 2px grey border on the left side of the scrollbar), but
> there's only an maximum width of 18px for a scrollbar in my screen
> design.

I'm fairly certain that the answer is 'no'. Firefox doesn't support
any scrollbar related CSS extensions as they're not part of the W3C
spec.

Scrollbars are something you must consider to be 'part of the
operating system' which is ultimately the user's domain, not yours as
the page author. It's a bit of a firey area, but it's the view of the
CSS-WG (and the majority of comments I've ever seen on the matter, at
least) that it's out of the scope of the page content to mess with
browser chrome.

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Opera 8.5 released, now no registration fee ad-free permanently

2005-09-21 Thread Ben Ward
I have generally tested in Opera 7+, but I do find that although its
standards support is generally outstanding, it pulls off some
genuinely odd quirks that can really mess you about.

One of the problems with targetting it came from the 'but people might
not pay to upgrade to version 7/8' dilemma, thus you maybe ended up
supporting more older versions than you might do for, say, Firefox.
I'm glad that is no-longer part of the browser-support equation.

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] vCard and Webforms

2005-08-29 Thread Ben Ward
I'm not convinced that it can be done exactly as you describe.

Browsers - Mozilla for sure - have restrictions on what you can do
with external files - especially drag+drop. For example, the reason
you can't drag-and-drop a file onto a 'file' form control in Firefox
is because this would make it scriptable and would expose the browser
to all manner of vulnerabilities (it would allow a page to populate
the path in the 'file' control, so a malicious web page could
auto-fill a hidden control with the path to your browser history,
passwords file or somesuch).

I don't know about the other major browsers, but I suspect they have
similar scripting limitations.

The rest of the idea sounds pretty doable, as best I can tell:

What you could do, would be to have a 'file' control at the start of
your form, and allow people to upload a vCard manually through that.
You could do the processing of the vCard server side and send back
some serialised form to populate the form with.

I think that's as neat as you can get it.

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] accessibility - opening new windows philosophy

2005-08-15 Thread Ben Ward
On the whole, I'm very much in the 'user decide' camp. However, there
is some argument for opening PDFs and other
'not-normally-browser-native' media types in new windows (citing the
confusing ways in which plug ins behave).

Personally, I like everything to download and be opened by a native
application (especially PDFs!), but for coping with the default
behaviour of opening the in-browser plug-in, I /might/ give
consideration to new windows.

The best option I can think of a 1am is to clearly offer a second
'open in new window' link, probably inserted onload using script. That
way, the user can choose how to open it and if they pick the 'open'
link that sits next to an 'open in new window' link, they are given
some hint that the document will open in the SAME window, and thus get
around some of the back button/close button confusion mentioned above.


The other 'new window' situation I can think of relates to some 'web
applications'. For example, on the site I maintain, we have a Reseller
Locator that was designed with minimal header and footer to reduce
clutter. Although a legacy app (so it might not be designed this way
if we did it again) in this case it aids the usability of the
application to have the reduced interface.

However, this then removes a lot site navigation, so it makes more
sense to open it in a new window. The critical, REALLY REALLY
important thing I draw attention to when you have a system that (for
whatever reason) is better suited to a new window: *make it as obvious
as you can*.

  1) Add the new window behaviour to the link using script *after*
load. Have it open in the same, default window using a standard
hyperlink without script, so as not to lock out customised browser
configurations or scriptless fringe browsers.
  2) Define a default size for the app! Obviously allow it to be
resizeable, but if a new browser window appears that has exactly the
same dimensions as the 'primary' window it was spawned from, the user
is quite unlikely to twig that this is a different window at all.
They'll be confused when they can't click 'back' to return to the
original page.
If, however, you give the child window a different (ideally smaller)
size, then it will stand out from the main browser and the user won't
be as confused when wanting to return to the first page.

Still bad practice, I think, but those two rules are absolutely
non-negotiable for me when making the best of an imperfect situation!

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] "display: inline-block": valid or not? W3C validator says not.

2005-08-15 Thread Ben Ward
> CSS 2 - W3C recommendation
> CSS 2.1 - Working draft
> 
> Until CSS 2.1 becomes a recommendation, which shouldn't be too long
> (deadline for comments was July), the W3C validator will use what ever
> the current recommendation is.

Just to be a touch pedantic, CSS2.1 only needs to become a 'candidate
recommendation' before it should be considered 'the' CSS. This is
equivalent to what the W3C used to call a 'recommendation' and means
that browser makers should be looking to implement it as CR is feature
stable. CSS2.1 can't be a 'recommendation' until a full test suite has
been completed, which requires the assistance of browser makers
building implementations.

As such, the validator may well start responding to CSS2.1 syntax
earlier than 'recommendation'. We'll see.

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] self-counting list items

2005-08-09 Thread Ben Ward
Yes, it's already implemented in the development versions of Firefox.
If you download Deer Park Alpha 2 (for TESTING!), you should be able
to play with all the CSS improvements.

http://developer.mozilla.org/devnews/index.php/2005/07/12/deer-park-alpha-2-released/

Ben
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Styling Form Elements

2005-08-03 Thread Ben Ward
At the present time, Safari has minimal support for styled form
controls. Safari 2 on Tiger seems to support some colouring and
sizing, but little else. It was announced earlier in the week,
however, that the Safari team are working on a rewrite on their forms
code with a view to making them stylable.

As to where that fits in to future release schedules, however, is
anyone's guess.

Ben

On 8/3/05, David Hucklesby <[EMAIL PROTECTED]> wrote:
> Chris Kennon wrote:
> >
> >Found this article on styling form elements
> >(http://www.picment.com/ articles/css/funwithforms/),
> >unfortunately, it fails in Safari. Any suggestions or filters for
> >making a suitable presentation in Safari?
> >
> Chris,
> Styling forms can be an exercise in frustration. 456 Berea Street
> has done some comprehensive tests, with screenshots, that show
> what is possible - and not:
> 
> 
> 
> 
> Cordially,
> David
> --
> David Hucklesby, on 8/2/2005
> 
> --
> 
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Firefox MAC OSX checkbox keyboard tabbing problem

2005-07-28 Thread Ben Ward
Mac OSX has a system preference for 'Enable full keyboard access'
which in Safari at least is responsible for controlling whether you
can access form controls with the keyboard. Switching it on allows you
to do it.

I've left my Mac at home today, so haven't been able to check, but my
guess would be that Firefox may be respecting the same setting.

Ben

On 7/28/05, Focas, Grant <[EMAIL PROTECTED]> wrote:
> Hi,
> I've discovered a problem with Firefox and checkboxes and want to see if
> anyone elses experience is the same.
> I'm using Firefox 1.06 on Mac OSX 10.2.8 (though it also occurs in
> Firefox 1.04) and cannot use a keyboard to navigate to a checkbox.
> Two example pages where it does not work are:
> http://www.quirksmode.org/js/formex.html
> http://www.w3.org/WAI/UA/TS/html401/cp0101/0101-ACCESSKEY-CHECKBOX.html
> 
> It is working fine on Firefox on PC.
> 
> Notice that in the first page the radio buttons, select, submit and
> reset also will not recieve focus.
> 
> Grant Focas
> 
> 
> **
> This message is intended for the addressee named and may contain
> privileged information or confidential information or both. If you
> are not the intended recipient please delete it and notify the sender.
> **
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] using scalable vector graphics

2005-07-19 Thread Ben Ward
Yes, fallback content can be a normal  element with a fallback
bitmap image, and further fallback alt-text.

To make the width dynamic you need to do two things. 
  1) Your SVG image mustn't declare a fixed width in itself
  2) You need to do the sizing with CSS.

My preferred way is to place the object in a container (which you have
to do anyway) and use CSS to make the object size to width: 100%.
Then, no-matter what size your container is, the object should resize
smoothly.

I have a crude example at home which I'll post for you later on.

Ben

On 7/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Ben Ward wrote:
> > Use the  tag, just like we do with Flash. The SVG mimetype
> > ("type" atrribute) is "image/svg+xml" so you'd have something like:
> >
> > 
> >   
> > 
> 
> would the fall back content maybe be a jpg, gif or png of the svg image?
> 
> 
> > You can add width and heigh into that if you need to (though that
> > rather defeats the purpose of using vector graphics). No  tags
> > needed at all. I can't fathom why you've been advised to use 
> > at all, I must say.
> 
> when i googled the question, adobe support was one hit and they said in
> their explanation to  the graphic in the html.
> 
> if i wanted to use this image as a background image to fit the viewport
> or container, regardless of the users resolution, how would i do this?
> 
> dwain
> 
> 
> 
> --
> Dwain Alford
> [EMAIL PROTECTED]
> http://www.alforddesigngroup.com
> 
> "The artist may use any form which his expression demands;
> for his inner impulse must find suitable expression."
> Wassily Kandinsky, "Concerning The Spiritual In Art"
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] using scalable vector graphics

2005-07-18 Thread Ben Ward
Use the  tag, just like we do with Flash. The SVG mimetype
("type" atrribute) is "image/svg+xml" so you'd have something like:


  


You can add width and heigh into that if you need to (though that
rather defeats the purpose of using vector graphics). No  tags
needed at all. I can't fathom why you've been advised to use 
at all, I must say.

Ben
**
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] REL & REV

2005-07-13 Thread Ben Ward
Microformats.org have a nice little item in their FAQ about rel & rev
and some very useful 'plain english' expansions of common rel and rev
relationships. It cetainly cleared a few things up for me!

Ben

On 7/13/05, Patrick H. Lauke <[EMAIL PROTECTED]> wrote:
> Chris Kennon wrote:
> 
> > After pouring over endless minutiae, if yet to grasp when and how to
> > use  &  after having seen it numerous  times,
> > peering at the code of many respected sites.
> 
> Right...first of all, I think that out of the two only rel is most
> commonly used, as rev does seem to cause weird logic conundrums and is
> not really necessary in most simple situations.
> 
> The HTML 4 spec states:
> 
> "rel = link-types [CI]
>  This attribute describes the relationship from the current document
> to the anchor specified by the href attribute. The value of this
> attribute is a space-separated list of link types.
> 
> rev = link-types [CI]
>  This attribute is used to describe a reverse link from the anchor
> specified by the href attribute to the current document. The value of
> this attribute is a space-separated list of link types."
> 
> http://www.w3.org/TR/html4/struct/links.html#adef-rel
> 
> To give an (hopefully clearer) example:
> 
> say you have documents that make up a sequence, like separate chapters
> in a book where each document is a chapter, and you want to define the
> relationship between them with LINK elements to say which is previous
> and which is next in the set.
> 
> Document1 has a link rel="next" to Document2 - "Document2 has a
> relationship with me in that it's the next document in the set"
> 
> Document2 has (although nobody does this) a link rev="next" to Document1
> - "I have a relationship with Document1 in that *I* am Document1's next
> document in the set"
> 
> Document2 also has a normal link rel="previous" to Document1 -
> "Document1 is my previous document in the set"
> 
> which is reciprocated in Document1 with a link rev="previous" to
> Document2 - "I am Document2's previous document in the set"
> 
> You see, the rev is basically used to reciprocate what the rel in the
> other document said.
> 
> For simple relationships like this, it's fairly straightforward...but it
> can start being complicated when one document is the glossary and it
> needs to rev to any page that rels to it (every page would have a single
> link rel="glossary", but the glossary page itself would have a link
> rev="glossary" for every single page that references it with a
> rel...madness)
> 
> In practice, I have never encountered revs in the wild.
> 
> Hope this makes some kind of sense...
> 
> --
> Patrick H. Lauke
> __
> re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
> www.splintered.co.uk | www.photographia.co.uk
> http://redux.deviantart.com
> __
> Web Standards Project (WaSP) Accessibility Task Force
> http://webstandards.org/
> __
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Another Browser Checking Question

2005-06-22 Thread Ben Ward
If you're testing in Firefox 1.04 and Internet Explorer then there's
no need (unless you're doing ActiveX, in which case Netscape 8 has
some custom restrictions that you'd want to check against).

Just remember that it will take time for Netscape to stay up to date
with Firefox: When Fx1.1 arrives in a few months the rendering will
about 12 months ahead of Netscape 8. If you keep testing the
equivilent Firefox version to the netscape versions though then the
rendering will be identical.

Ben

On 6/22/05, Erica Jean <[EMAIL PROTECTED]> wrote:
>  
>  
> Netscape 8.0? 
>   
> It uses the IE and the Firefox rendering engines... Firefox by default, and
> switches to IE on "trusted" sites so that the sites "appear correctly"
> (Microsoft.com anyone?) 
>   
> Is it worth checking in? Really? 
>   
> *is not wanting to cram up my precious hard drive space with redundant
> browsers that will show little to no difference at all in my designs* 
>   
> Thanks again. 
> -Erica 
>  
>  


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Regarding foreign languages

2005-06-02 Thread Ben Ward
You need both because the language of the page and the encoding of the
characters in the document are different things.
UTF8 does not tell you which language you're using, and the language
attributes to not exist for the purpose of rendering characters
correctly.

A page in UTF-8 could be in any language, it doesn't tell you which.
But the language attribute(s) are used for other things. Since you can
select them with CSS, a web browser can apply regionalised quotation
marks to blocks of a document if you've declared the langauge.  A
screen reader will use different libraries to read different
languages, too. There are a variety of 'beyond the browser' uses for
the attribute.

For further reference: You also use both "lang" and "xml:lang" in
XHTML transitional for backward compatibility with HTML4, whilst in
strict mode "xml:lang" is all you need.

In your case, since the page is mostly in English I would have
lang="en" in the  element, and as you suggest, put lang="zn" in
the relevent form elements or parent containers as necessary.

Ben

On 6/2/05, Vaska. WSG <[EMAIL PROTECTED]> wrote:
> It's for a multilanguage site and base language will be English.
> Everything on the form will be English except the actual input
> (textarea).  Would it hurt anything if I just kept the lang declaration
> as EN in the header?  Or, since the input will be Chinese should it be
> ZN?  Or, do I need to be more specific and delcare lang=ZN on the
> textarea itself?
> 
> I was wondering though...since it's ALL utf-8 it might not be necessary
> to declare lang=whatever at all?
> 
> Out of curiousity, I'm not sure why we need to declare lang and
> xml:lang since utf-8 (I believe) is all we really need?
> 
> 
> On Jun 2, 2005, at 4:21 PM, Ben Ward wrote:
> 
> > The language in your html element should be the language of the page.
> > If you have a section of the page (be that a parapraph, form,
> > anything) which uses a different language then you can add a lang and
> > xml:lang attribute to that as well. HTML is generally rather good at
> > doing multi-lingual documents.
> >
> > I could do this on a page (this is condensed down and is missing some
> > attributes, but I just want to show the xml:lang/lang behaviour):
> >
> > 
> > 
> >
> > 
> > 
> >
> > 
> >   
> > 
> >
> > 
> > 
> > 
> >
> > The language declaration doesn't restrict the characters you can use
> > in forms, regardless. So you don't need to add a language attribute to
> > your sub-elements unless you are explicitly requiring Chinese input.
> > Obviously if it's an all chinese site then it would make sense to
> > change the language value in the  element itself.
> >
> > Ben
> > **
> > The discussion list for  http://webstandardsgroup.org/
> >
> >  See http://webstandardsgroup.org/mail/guidelines.cfm
> >  for some hints on posting to the list & getting help
> > **
> >
> >
> >
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Regarding foreign languages

2005-06-02 Thread Ben Ward
The language in your html element should be the language of the page.
If you have a section of the page (be that a parapraph, form,
anything) which uses a different language then you can add a lang and
xml:lang attribute to that as well. HTML is generally rather good at
doing multi-lingual documents.

I could do this on a page (this is condensed down and is missing some
attributes, but I just want to show the xml:lang/lang behaviour):








  






The language declaration doesn't restrict the characters you can use
in forms, regardless. So you don't need to add a language attribute to
your sub-elements unless you are explicitly requiring Chinese input.
Obviously if it's an all chinese site then it would make sense to
change the language value in the  element itself.

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

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



Re: [WSG] Style PRE with word wrap?

2005-05-31 Thread Ben Ward
Fair point,  was indented purely for presentation. However, it
does have a small bit of semantic significance, insofaras it says
"whitespace is important". Sure, it indents that in terms of
presentation but the implied meaning is not irrelevent (especially in
the context of languages where the whitespace is important (Pyton?
Possibly). This is the way in which I think of it at the moment, until
XHTML2's  element gains support.  replaces 
for code and effectively 'fixes' the problem.

Although, all that said, does the  tag apply default white-space
formatting in the major browsers? If so, wrapping it in a  would
be ample. I seem to remember that for some reason  didn't format
the whitespace without CSS, though.

Ben

On 5/31/05, Patrick Lauke <[EMAIL PROTECTED]> wrote:
> > Ben Ward
> 
>   is semantically pretty sound
> > for this, since code is pre-formatted and some languages are
> > white-space sensitive, for example.
> 
> To split hairs, though, the problem with  seems to be that it
> appears very much like a presentational, rather than a semantic element.
> Any semantics seem to be inferred by the fact that the content is
> preformatted, which is a rather weak argument...by the same rationale,
> one might as well say that , ,  etc are semantic.
> 
> Heck, even the spec's definition
> 
> 'The PRE element tells visual user agents that the enclosed text is
> "preformatted".'
> http://www.w3.org/TR/html4/struct/text.html#edef-PRE
> 
> strikes me as purely presentational.
> 
> Patrick
> 
> Patrick H. Lauke
> Webmaster / University of Salford
> http://www.salford.ac.uk
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Style PRE with word wrap?

2005-05-31 Thread Ben Ward
Prabhath -  is an inline element, so while is should probably be
included somewhere in marking up code, you need something else on the
outside of it to create the block.  is semantically pretty sound
for this, since code is pre-formatted and some languages are
white-space sensitive, for example.

Vaska - Unfortunately there's nothing in the CSS2 spec that I know of
to do what you want (see:
http://www.w3.org/TR/REC-CSS2/text.html#white-space-prop). You can
either obey the white-space in the source code or automatically wrap
to the box, but not both.

The equivalent part of the CSS Level 3 spec is massively improved
though; providing additional white-space values and additional
properties for controlling individual parts of white-space handling.
"white-space" itself now effectively sets different combinations of
values for these new properties. I have no idea what
Opera/Firefox/Safari/K support is like for this yet, but I believe
that the text module is pretty stable spec wise, so expect some
implementations sooner rather than later, if not already. See:
http://www.w3.org/TR/css3-text/#white-space

If implementations do exist, you might be able to compromise your
design by using a CSS2 compatible white-space setting and overflow
scrolling for any long lines, then set the CSS3 value afterwards for
better handling in newer browsers as and when they support it.

Cheers,
Ben

On 5/31/05, Prabhath Sirisena <[EMAIL PROTECTED]> wrote:
> > I'm trying to make a page that will display some source code.  The PRE
> > tag works very will with retaining \t and \n but I can not find a way
> > to make it wrap words.  Words fly off the monitor...
> 
> Shouldn't you be using the code tag instead? It's a semantically better 
> option.
> 
> However, the problem will still remain.
> 
> Prabhath
> http://nidahas.com
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Definition lists for comments in blogs

2005-05-30 Thread Ben Ward
> What would be wrong with doing something like this?
> 
> Comment Title
> 
> Posted by foobar on foobar
> 
> 
> 
> Comment text
> 
> 

Nothing 'wrong', as such. The  surrounding the 'comment text'
paragraph is superfluous and could be dropped, but semantically it's
pretty sound.

The semantic question to ask there: "is each individual comment really
a subsection of the page?" (which a header signifies). The answer
could be yes or no there, I err on "no" but I see how people could
differ.
If you were to mark up three comments using your above example, you
have 3 different sub-sections in your page structure.

Ultimately, the reason for preferring a definition list is that the
spec says you can use it to structure a dialogue and since that's what
comments are, it does rather make sense.
Using a definition list describes everything you've achieved with 
and , but /also/ makes it very clear that the comments are a
related sequence. Arguably a  also describes a much closer
relationship between the comment title ( --> ) and the
information (date , author and comment text (all )), than a
heading and following paragraphs.

There's not much in it really, and there comes a point when choosing
one highly-optimised semantic structure over another highly-optimised
semantic structure shouldn't matter. Both are pretty good.

Ben
**
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] elements and what they can contain

2005-05-29 Thread Ben Ward
It is very much a legacy thing these days, since it is being "solved"
for XHTML 2.0, insofaras you can attach the href="" attribute to
pretty much any element you like, regardless of block|inline
condition.

A navigation menu item could be 'Homepage'
without the extra  tag. That's the way I remember it from last
time I read that spec, anyway.

I know that doesn't solve the problem in production sites for about
the next decade, but for reference sake it's worth noting.

Ben

On 5/27/05, Peter Ottery <[EMAIL PROTECTED]> wrote:
> Damien wrote:
> > As to your question about  tags for block level elements, can you
> > give an example when you would use this?
> 
> not a good one, no :) i had a fleeting thought like "what if, for some
> ungodly reason, you wanted to link an entire sidebar div to another
> page" - but it was fleeting. just me being too questioning :)
> 
> john wrote:
> > In terms of the document tree, and as far as a validator is
> > concerned its still a block or inline element as defined by the DTD.
> 
> a, ok. cool. explains a few things. silly me.
> see you at the pub :-)
> 
> pete
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Photo gallery & standards?

2005-05-29 Thread Ben Ward
I think the problem you have there is that you're breaking the
pictures down in too many different ways on a single page. You might
find it more managable if you allow users to choose the presentation:

For example, you can separate browsing by:
* Photographer
* Major catagory
* Country (maybe, depending on the span of your site)

Then, if you're browsing by photographer you can simplify your output
by just listing the most recent photographs next to each person in the
list. At the moment you have Photographer -> Multiple Albums (which
then indicates there are multiple photographs to view).
After a user has picked out a photographer of their liking, /then/ you
can offer the list of organised albums, comments and so forth on the
author page.

That should hopefully be far more managable for you (not to mention
for someone viewing the site)!

By reducing the overflow of information, you should find that your
code can simpify right down. At the moment you're using a lot of
tables largely for layout. The above "photographer -> recent photos"
listing could work with a simple definition list, styled with CSS.

So,


  Pete Flint
  
  
  
  
  
  

  Terry Gulliford
  
  
  
  
  
  




In the above case, each "" would of course be a different
recent photograph by that photographer, but I'm just using it as a
placeholder to avoid cluttering the example.

The following CSS is simple, but might give you some idea of the same
layout you have on your current page.

dl,
dt,
dd
{
  display: block;
  margin: 0; /* this clears the default margin on  elements */
}

dd.photo {
  float: left;
  border: 2px solid black;
}

/* then, to ensure that each new photographer appears on a new line,
clear all  elements */
dt
{
  clear: both;
}
  
That's completely untested (sorry!), but should give you some idea of
what I mean (hopefully!).

Cheers,

Ben
On 5/29/05, Jad Madi <[EMAIL PROTECTED]> wrote:
> actually i'm having a problem in my project, I have to have category
> for every person, with his albums
> so the site become so ugly and so huge, and the current content is
> only 20% of what I have
> would you mind to take a look
> http://joite.org/gallery/
> 
> 
> On 5/29/05, Kornel Lesinski <[EMAIL PROTECTED]> wrote:
> > On Sun, 29 May 2005 15:46:29 +0100, Chris Kennon <[EMAIL PROTECTED]> wrote:
> >
> > > How to Create a Photographic Gallery Using CSS:
> > > http://www.webreference.com/programming/css_gallery/index.html
> >
> > I don't like it. It works only on hover and that's Bad Thing for usability
> > and accessiblity.
> >
> > I can't use keyboard.
> > I can't get link to certain image.
> > I can't copy image or get it's properties.
> > I can't leave page open on certain image (try not getting lost in
> > 100-image gallery).
> > I can't use Opera's slideshow feature.
> >
> > For me even Apache's simple directory listing makes better gallery than
> > that.
> >
> > --
> > regards, Kornel Lesiński
> > **
> > The discussion list for  http://webstandardsgroup.org/
> >
> >  See http://webstandardsgroup.org/mail/guidelines.cfm
> >  for some hints on posting to the list & getting help
> > **
> >
> >
> 
> 
> --
> Web standards Planet
> http://www.w3planet.info/
> Personal Blogger
> http://www.EasyHTTP.com/jad/
> EasyHTTP Network
> http://www.EasyHTTP.com
> 


-- 
http://www.ben-ward.co.uk


Re: [WSG] Definition lists for comments in blogs

2005-05-29 Thread Ben Ward
Ahh, but the problem with using  there is that you're
trying to differentiate between content from the site owner and
content from contributors. However, both those people are 'authors' on
the blog, the blog article and blog comments are both first-hand
content.
 marks up content that is quoted from *another source*,
not a secondary author. A comment on a blog does not exist in any
other source (online or offline), so you're not 'quoting' it at all.

I think the best way to think about it is that with a blog, there is a
difference between the site 'owner' and the site authors. If you
enable comments on your blog, you are inviting the world in to be
authors too.

As a curious twist though (given the way in which most blogging
software will merge Trackback and Pingback with directly contributed
comments) it /would/ be appropriate to  the content
snippet from a pinging site, since in that situation the content /is/
second hand.

I can see the dilemma, choosing to present the chronological order
(ol) vs. presenting more detailed structuring of dialogue (dl).

Given that the HTML4 spec. explicitly says that you can use a  for
dialogue, the content is implicitly in order. For me, that is a good
enough justification for using the more detailed markup of a .

Not 100% sure of how I'd do it; maybe something like this:


  Steve
  28th May 2005, Midday
  Blah Blah Blah Foo

  David
  29th May 2005, Early Morning
  I concur with all that Blah

  
Any additional meta data (maybe "in reply to") would be added as
further  elements before the body text.

For styling (albeit rather ambitious with my CSS support), I might use
a CSS counter to number each  (the  has an implicit order),
plus some generated content to add a "Comment by " and "on " prefix to
the author and datetime fields respectively. It depends on your
browser target for something as personal as a blog.

Ben

On 5/27/05, heretic <[EMAIL PROTECTED]> wrote:
> > At x:xxpm so-and-so said:
> > blah blah blah
> 
> Accurate I suppose although I'm a bit undecided about numbering
> inserted as content. Similarly been thinking about markup for search
> engine results.
> 
> > 
> > At x:xxpm so-and-so said:
> >  blah blah blah
> > 
> > 
> 
> Thinking this through  and  mark up sections of
> content which did not originate from the document's author. So I guess
> this is semantically correct on the basis that the hosting site did
> not create the content.
> 
> Thinking back to my search results scenario, the document summary
> could be considered a quote as well.
> 
> Hmmm. Mental cogs grinding. Hang on, it's supposed to be friday night ;)
> 
> h
> 
> --
> --- 
> --- The future has arrived; it's just not
> --- evenly distributed. - William Gibson
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Anyone see this?

2005-05-26 Thread Ben Ward
Yes, it's an Internet Explorer wrapper. Another variation on the
Maxthon/Avant theme.

On 5/26/05, Thomas Livingston <[EMAIL PROTECTED]> wrote:
> Curious about what The Pros ;-) thought of this.
> 
> Anyone got any insight/info/anecdotes/opinions? Is it a new wrapper
> on IE? Is it compliant?
> 
> http://www.deepnetexplorer.com/
> 
> 
> Thomas Livingston
> Senior Multimedia Artist
> Media Logic
> www.mlinc.com
> 
> ---
> www.browsehappy.com
> 
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] best way to approach markup of an address

2005-05-23 Thread Ben Ward
Apologies - I hit send too soon and the example was wrong. I meant
that you could end up with this:


   
CAMELFORD OFFICE:
20 Market Place
Camelford
Cornwall
PL32 9PD
TEL 01840 212938
FAX 01840 213596
  

I might also be inclined to put semantic class names on each of those
addresses (such as "street-address", "telephone", "fax". In the
future, this would allow you to use CSS to generate the "Tel" and
"Fax" prefixes for you, or insert an appropriate icon graphic etc.

Ben


On 5/23/05, Ben Ward <[EMAIL PROTECTED]> wrote:
> Nothing 'wrong' with that I don't think. I think that the street
> address should probably only be contained within a single , though
> (since it is a single entity). Lines could be broken with  as
> appropraite.
> 
> I think it would then be appropraite to wrap the inner text of each
>  with an  too, so you have:
> 
> 
>  CAMELFORD OFFICE:
>  20 Market Place
>  Camelford
>  Cornwall
>  PL32 9PD
>  TEL 01840 212938
>  FAX 01840 213596
>
> 
> 
> 
> The WHATWG Web Apps draft has an expanded definition for 
> which seems to be semantically identical to the existing HTML4 spec,
> but provides a more verbose explaination:
> http://whatwg.org/specs/web-apps/current-work/#the-address
> 
> On 5/23/05, designer <[EMAIL PROTECTED]> wrote:
> > So, is this example 'wrong' ?
> >
> > 
> >   CAMELFORD OFFICE:
> >   20 Market Place
> >   Camelford
> >   Cornwall
> >   PL32 9PD
> >   TEL 01840 212938
> >   FAX 01840 213596
> > 
> >
> > It's what I generally use for the contact address of whatever business site
> > I'm producing.  It has the advantage of allowing the  which, with
> > appropriate CSS formatiing, makes for a nice display of the information.
> >
> > (Please tell me it's OK :-)
> >
> > Bob McClelland,
> > Cornwall (U.K.)
> > www.gwelanmor-internet.co.uk
> >
> > **
> > The discussion list for  http://webstandardsgroup.org/
> >
> >  See http://webstandardsgroup.org/mail/guidelines.cfm
> >  for some hints on posting to the list & getting help
> > **
> >
> >
> 
> 
> --
> http://www.ben-ward.co.uk
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] best way to approach markup of an address

2005-05-23 Thread Ben Ward
Nothing 'wrong' with that I don't think. I think that the street
address should probably only be contained within a single , though
(since it is a single entity). Lines could be broken with  as
appropraite.

I think it would then be appropraite to wrap the inner text of each
 with an  too, so you have:


 CAMELFORD OFFICE:
 20 Market Place
 Camelford
 Cornwall
 PL32 9PD
 TEL 01840 212938
 FAX 01840 213596
   



The WHATWG Web Apps draft has an expanded definition for 
which seems to be semantically identical to the existing HTML4 spec,
but provides a more verbose explaination:
http://whatwg.org/specs/web-apps/current-work/#the-address

On 5/23/05, designer <[EMAIL PROTECTED]> wrote:
> So, is this example 'wrong' ?
> 
> 
>   CAMELFORD OFFICE:
>   20 Market Place
>   Camelford
>   Cornwall
>   PL32 9PD
>   TEL 01840 212938
>   FAX 01840 213596
> 
> 
> It's what I generally use for the contact address of whatever business site
> I'm producing.  It has the advantage of allowing the  which, with
> appropriate CSS formatiing, makes for a nice display of the information.
> 
> (Please tell me it's OK :-)
> 
> Bob McClelland,
> Cornwall (U.K.)
> www.gwelanmor-internet.co.uk
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] best way to approach markup of an address

2005-05-22 Thread Ben Ward
Lea - I think the problematic part of the  element as
described in Geoff's link is the part reading "authorship for the
current document". Yes, wrapping a street address is correct. However,
it specifies that the address must be related directly to the document
(e.g. the author's or owner organisations address). You can't,
apparently, use it to mark up arbitrary addresses in a page.

My interpretation from that link (contrary from what I previously
believed) you couldn't markup the address of your companies resellers
(for instance, you have a list of them on a single page) with the
 element as their address isn't related to the authorship of
the document.

I do agree with Geoff that this is something of a waste of an element.

Ben

On 5/22/05, Lea de Groot <[EMAIL PROTECTED]> wrote:
> On Mon, 23 May 2005 06:48:55 +1000, Geoff Deering wrote:
> > The first is correct, but  should only be used when
> > referencing the author of a document.
> >
> > http://www.w3.org/MarkUp/html3/address.html
> > http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.3
> >
> > It's not used for general contact information, which is kind of waste
> > of a good element.
> 
> Happily, both of the examples you cited contradict you.
> Do put street address in ADDRESS tags :)
> 
> warmly,
> Lea
> --
> Lea de Groot
> Elysian Systems - I Understand the Internet 
> Search Engine Optimisation, Usability, Information Architecture, Web
> Design
> Brisbane, Australia
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] best way to approach markup of an address

2005-05-22 Thread Ben Ward
I would go for the first one, since in this I think the  is
given semantic value as a separator (even though, technically the
element has zero semantic value). The first set of markup would by
default display a nice, multi-line formatted address in all browsers
and could be formatted into a comma-separated, single line address
using CSS.

The second is definately wrong since it describes three separate addresses.

I think it's one of the increasingly rare situations where  is
the correct element. Although, if being sickeningly pedantic you could
argue that the lines should be formatted as an ordered list. I'm not
sure that you can legally wrap an  in an  though.

Ben

On 5/22/05, Bruce Gilbert <[EMAIL PROTECTED]> wrote:
> for an address, which way is best
> 
> 
> 1st line
> 2nd line
> 3rd line
> 
> 
> or
> 
> 
> 1st line
> 2nd line
> 3rd line
> 
> TIA!
> --
> ::Bruce::
> **
> The discussion list for  http://webstandardsgroup.org/
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 


-- 
http://www.ben-ward.co.uk
**
The discussion list for  http://webstandardsgroup.org/

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