Re: [WSG] What do we say if we don't say click?
interesting discussion I get a lot of mobile phone users here. click would definately not be a suitable word to use on any page mobile phone users are likely to look at. ...however I might use that word on pages that require javascript such as those that use an external api to display maps. The only people able to use those pages are people using a web browser that can execute javascript... and 99.99% of such users would be using a mouse or a pointing device designed to emulate a mouse! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] input name and id
On 18/04/2007, at 1:56 PM, Mariusz Nowak wrote: 'name' is not required by specification (at least as far as I understand specification) - it's a bit striking to me as what's the use of input element without assigned name?? Exactly. Perhaps I should have said 'name' is **needed** to process form controls and avoided language with special meaning within the spec. see: http://www.w3.org/TR/html401/interact/forms.html#successful- controls kind regards Terrence Wood. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] input name and id
On 16/04/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: Name and ID serve two different purposes. ID is used to identify the element's node in the document [1]. Name is used to identify the element's value in the form submission posted back to the server [2]. OTOH, according to the HTML 4.01 Strict DTD, name is #IMPLIED, not #REQUIRED, so the book is incorrect. [3] The book is correct. It's a question of HTML having rules that DTD can't represent. In this case, that input elements can be form controls or form functionality (i.e. type attribute has a value of submit or reset). The name attribute is required on form controls but not on form functionality. The DTD format doesn't allow this type of granularity however. In other words, just because something is valid according to the HTML DTD doesn't mean it's valid according to the HTML specification. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] input name and id
On 19 Apr 2007, at 12:03:22, liorean wrote: On 16/04/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: Name and ID serve two different purposes. ID is used to identify the element's node in the document [1]. Name is used to identify the element's value in the form submission posted back to the server [2]. OTOH, according to the HTML 4.01 Strict DTD, name is #IMPLIED, not #REQUIRED, so the book is incorrect. [3] The book is correct. It's a question of HTML having rules that DTD can't represent. In this case, that input elements can be form controls or form functionality (i.e. type attribute has a value of submit or reset). The name attribute is required on form controls but not on form functionality. The DTD format doesn't allow this type of granularity however. A DTD is perfectly capable of specifying that an attribute is required: it uses the syntax #REQUIRED. The spec for the name attribute of the input element states that it is #IMPLIED, not #REQUIRED, therefore it is not correct to say that the name is required. The name is _necessary_ for a control to be a successful control, but the book is still wrong if it states that the attribute is _required_ by the spec. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] input name and id
On 19/04/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: A DTD is perfectly capable of specifying that an attribute is required: it uses the syntax #REQUIRED. The spec for the name attribute of the input element states that it is #IMPLIED, not #REQUIRED, therefore it is not correct to say that the name is required. Yes, that is true. However, a DTD is not capable of stating that the attribute is optional ONLY when the value of the type attribute is reset or submit. The attribute is required if that is not the case. The name is _necessary_ for a control to be a successful control, but the book is still wrong if it states that the attribute is _required_ by the spec. You're right on one point. If the book states that it's required for ALL input elements, then the book is wrong. However, saying it is optional is equally wrong, because it isn't optional for form control input elements (i.e. all type attribute values other than reset and submit, including the value button, entirely independent of whether the form control may be successful or not). -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say click?
Michael MD wrote: interesting discussion I get a lot of mobile phone users here. click would definately not be a suitable word to use on any page mobile phone users are likely to look at. ...however I might use that word on pages that require javascript such as those that use an external api to display maps. The only people able to use those pages are people using a web browser that can execute javascript... and 99.99% of such users would be using a mouse or a pointing device designed to emulate a mouse! Interesting. Can you point to the source of this statistical declaration? I can point to semi-credible stats showing that 4% of users cannot (do not?) support JavaScript [http://www.thecounter.com/stats/2007/March/javas.php], but I'm curious as to where you can state that 99.99% of user would be using a mouse or similar pointing device. Hard statistical data like this is very difficult to come by, and so any credible source is interesting to both myself, and I'm sure others. Cheers! JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say click?
On a related note, though not involving galleries, I find a lot of our clients want to have linked text along the lines of Click here for more details on product x. I have managed to fairly much insist that we always use the entire sentence as a link to show context, rather than just the click here that they tend to want being the only linked part. The main reason I have not been able to get rid of the click here part altogether though is due to an absence of a suitable alternative that incorporates other technologies... Does anyone have any suggestions for these circumstances? Thanks James *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] MS Smart Tags
Hi, It might sound silly but I first found out about MS Smart Tags yesterday. I found an article on ALA about them from 2001. Just wanted to ask, does anyone know what happened with them since? And would the meta tag: meta name=MSSmartTagsPreventParsing content=true / work? or is it still necessary? Cheers, Elle *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] making tables/rows/cells in IE lose their tableness via CSS
Yeah, it was quite wild as I remember ... The other day I was playing with Eric's CSS Charts and wanted to have the actual data in table, repositioning them somehow for display. It was rather hacking the elements to the position. -- Jan Brasna :: www.alphanumeric.cz | www.janbrasna.com | www.wdnews.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Caching / preloading images
Good day all, I am seeking informations about rendering a fluid site visit, I mean avoiding the most possible waiting time / loading animation. For an online shop which will contain 4 modules on the same page : * Long list menu with a window decorate image for every text link rollover * manual carousel for the products , 3 products shown, one highlighted * customizable items per product * real-time preview with a zoom tool At this step to resume about what I know with the basic analysis / technical specification : * Everything on the client side (Green card for full Ajaxx, no alternative without javascript) * The menu itself should be available as the document is ready. So I am considering to preload the 50 hundred images maybe more * About the other, I am considering to first launch the current product and the items available for it only. Add a visual effect per images or images group to avoid the rendering slowly loading step by step pictures (I mean from a visitor point of view). * After all of this, decide about the required library I was just wondering about the methods to consider truely the problem ? Reports, articles, advises, statistics or just web developer experiences are welcome... to avoid the kernel panic junior webdev I believed the discuss is more about testing and DOM and Ajaxx subjects so I apologize for allowing myself to post to the two lists, Evolt and WSG. Best regards, -- Wcube . eQuesto Pierre-Henri LAVIGNE Web developer xhtml - css - dom 33, rue des Jeûneurs - FR 75002 Paris [EMAIL PROTECTED] Phone: +33(0)1 42 47 83 83 www.wcube.fr / www.equesto.fr *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] What do we say if we don't say click?
Doesn't More details on product x mean exactly the same thing as Click here for more details on product x if the whole line is a link? Surely people recognise links enough that they don't need to be told to click every single one? On Fri, 20 Apr 2007 03:10:12 +1000, James Leslie [EMAIL PROTECTED] wrote: On a related note, though not involving galleries, I find a lot of our clients want to have linked text along the lines of Click here for more details on product x. I have managed to fairly much insist that we always use the entire sentence as a link to show context, rather than just the click here that they tend to want being the only linked part. The main reason I have not been able to get rid of the click here part altogether though is due to an absence of a suitable alternative that incorporates other technologies... Does anyone have any suggestions for these circumstances? Thanks James *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Tyssen Design www.tyssendesign.com.au Ph: (07) 3300 3303 Mb: 0405 678 590 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say click?
James Leslie wrote: On a related note, though not involving galleries, I find a lot of our clients want to have linked text along the lines of Click here for more details on product x. I have managed to fairly much insist that we always use the entire sentence as a link to show context, rather than just the click here that they tend to want being the only linked part. The main reason I have not been able to get rid of the click here part altogether though is due to an absence of a suitable alternative that incorporates other technologies... Does anyone have any suggestions for these circumstances? One thing I try to encourage is to rephrase the statement to actually present the URL as part of the on screen text, for example: ...More information regarding foobar can be found at: a href=link_uri blah blahlink_uri/a. 1) almost everyone recognizes a structured URI as being a link, there is no ambiguity there 2) surprisingly, some people still print out web pages, and providing the actual uri in print benefits these people 3) making the uri the actual link text ensures that the link text is unique for the page 4) this is technology agnostic JF *blah blah in uri above = title, class or id declarations as required/desired *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] What do we say if we don't say click?
Hi John,
Do you ever find that your solution causes you page layout problems
(that is, including the uri as the link text)?
When I first encountered “web standards” folk, it was suggested to me
that including uris as link text wasn’t ideal for accessibility reasons,
because of screen readers reading them out (tedious and often
meaningless for end user – Patrick Lauke summarises this in a post to
the list back on 31 October 2005, “Re: [WSG] {WSG] What's the best way
to display links?”.
Placing the a href tag around descriptive text can be more meaningful
(just as placing the a href around Click Here can be meaningless).
But in the largely academic world that I work in, scholarly citation is
the key to what we do, so we see including a url in its full glory on
the page as necessary, and at present we do make it the text that is
linked. This sometimes causes me problems in the design, breaking page
layout – possibly because I am not a brilliant exponent of css -
especially when you are citing urls created by government departments
which ridiculously long.
I am aware of several workarounds, but haven’t found them satisfactory.
Cheers,
Helen
John Foliot wrote:
James Leslie wrote:
On a related note, though not involving galleries, I find a lot of
our clients want to have linked text along the lines of Click here
for more details on product x. I have managed to fairly much insist
that we always use the entire sentence as a link to show context,
rather than just the click here that they tend to want being the
only linked part. The main reason I have not been able to get rid of
the click here part altogether though is due to an absence of a
suitable alternative that incorporates other technologies... Does
anyone have any suggestions for these circumstances?
One thing I try to encourage is to rephrase the statement to actually
present the URL as part of the on screen text, for example:
...More information regarding foobar can be found at: a href=link_uri
blah blahlink_uri/a.
1) almost everyone recognizes a structured URI as being a link, there is no
ambiguity there
2) surprisingly, some people still print out web pages, and providing the
actual uri in print benefits these people
3) making the uri the actual link text ensures that the link text is unique
for the page
4) this is technology agnostic
JF
*blah blah in uri above = title, class or id declarations as
required/desired
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] What do we say if we don't say click?
John Faulds:
Surely people recognise links enough that they don't need to be told to
click every single one?
I agree. The verb ('click here', 'go to' etc) really shouldn't form part
of the link text.
kind regards
Terrence Wood.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] What do we say if we don't say click?
John Foliot wrote: semi-credible stats showing that 4% of users cannot (do not?) support JavaScript [http://www.thecounter.com/stats/2007/March/javas.php] Granted, this appears to be more reliable than 99.9% - but isn't javascript required in order for thecounter.com to gather stats, or do they use web bugs? I think it is (semi) safer to say 4% of visitors to sites using thecounter.com counters do not have javascript enabled =) kind regards Terrence Wood *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] What do we say if we don't say click?
My good people,
It's really a matter of simple common sense. Yes, we want to cater to
the largest possible audience. But in all reality, unless our site in
question is the first web page someone has ever encountered, they'll
understand that whether they click, press enter or any other possible
means of activation, following a link is following a link.
In my opinion, click here is a stupid thing to put in a link. The text
of the link should do its best to describe what it actually points to.
For example:
A link that says Books about birds. Pretty obvious what your click
or whatever will bring you to. Instructions for activating the link are
superfluous to say the least.
If I purchase that Book about birds and open it to the table of
contents, does the description of a chapter say, Turn to page 95 for
information about bluebirds?
No!
It'll say Bluebirds...page 95.
The method we would use to reach page 95 is out of context of the
information.
As far as the URL showing on printwell thats another beast altogether.
*Joseph R. B. Taylor*
Sites by Joe, LLC
/Custom Web Design Development/
Phone: (609) 335-3076
www.sitesbyjoe.com http://www.sitesbyjoe.com
Helen Morgan wrote:
Hi John,
Do you ever find that your solution causes you page layout problems
(that is, including the uri as the link text)?
When I first encountered “web standards” folk, it was suggested to me
that including uris as link text wasn’t ideal for accessibility
reasons, because of screen readers reading them out (tedious and often
meaningless for end user – Patrick Lauke summarises this in a post to
the list back on 31 October 2005, “Re: [WSG] {WSG] What's the best way
to display links?”.
Placing the a href tag around descriptive text can be more
meaningful (just as placing the a href around Click Here can be
meaningless). But in the largely academic world that I work in,
scholarly citation is the key to what we do, so we see including a url
in its full glory on the page as necessary, and at present we do make
it the text that is linked. This sometimes causes me problems in the
design, breaking page layout – possibly because I am not a brilliant
exponent of css - especially when you are citing urls created by
government departments which ridiculously long.
I am aware of several workarounds, but haven’t found them satisfactory.
Cheers,
Helen
John Foliot wrote:
James Leslie wrote:
On a related note, though not involving galleries, I find a lot of
our clients want to have linked text along the lines of Click here
for more details on product x. I have managed to fairly much insist
that we always use the entire sentence as a link to show context,
rather than just the click here that they tend to want being the
only linked part. The main reason I have not been able to get rid of
the click here part altogether though is due to an absence of a
suitable alternative that incorporates other technologies... Does
anyone have any suggestions for these circumstances?
One thing I try to encourage is to rephrase the statement to actually
present the URL as part of the on screen text, for example:
...More information regarding foobar can be found at: a
href=link_uri
blah blahlink_uri/a.
1) almost everyone recognizes a structured URI as being a link, there
is no
ambiguity there
2) surprisingly, some people still print out web pages, and providing
the
actual uri in print benefits these people
3) making the uri the actual link text ensures that the link text is
unique
for the page
4) this is technology agnostic
JF
*blah blah in uri above = title, class or id declarations as
required/desired
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
begin:vcard
fn:Joseph R. B. Taylor
n:Taylor;Joseph
org:Sites by Joe, LLC
adr:;;408 Route 47 South;Cape May Court House;NJ;08210;USA
email;internet:[EMAIL PROTECTED]
tel;work:609-335-3076
tel;cell:609-335-3076
url:http://www.sitesbyjoe.com
version:2.1
end:vcard
Re: [WSG] What do we say if we don't say click?
John Foliot wrote: semi-credible stats showing that 4% of users cannot (do not?) support JavaScript [http://www.thecounter.com/stats/2007/March/javas.php] Granted, this appears to be more reliable than 99.9% - but isn't javascript required in order for thecounter.com to gather stats, or do they use web bugs? good point... btw that 99.99% was never intended to be used as some kind of reliable statistic! so please don't quote it as such! - it was only a guess about something - perhaps I should have just said something like most... :-) I think it is (semi) safer to say 4% of visitors to sites using thecounter.com counters do not have javascript enabled =) I think I was talking about mobile phone users who in total would probably only barely be noticed by such web counters... (if they work by loading an image not all mobile browsers would display it on a page load and if it needs javascript then it would be a lot less again!) btw it seems that there are quite a few people out there who browse on their phones but do not often browse on a PC... so I don't think we can expect them all to be familiar with many of the conventions we might take for granted! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say click?
Terrence Wood wrote: John Foliot wrote: semi-credible stats showing that 4% of users cannot (do not?) support JavaScript [http://www.thecounter.com/stats/2007/March/javas.php] Granted, this appears to be more reliable than 99.9% - but isn't javascript required in order for thecounter.com to gather stats, or do they use web bugs? I think it is (semi) safer to say 4% of visitors to sites using thecounter.com counters do not have javascript enabled =) No argument, which is why I said semi-credible... like most web stats they are subject to numerous variables. However, for the sake of discussion, they can at least be referenced by all, unlike the incredulous 99.99% number I was questioning. JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] MS Smart Tags
Hi Elle, It might sound silly but I first found out about MS Smart Tags yesterday. I found an article on ALA about them from 2001. Just wanted to ask, does anyone know what happened with them since? And would the meta tag: meta name=MSSmartTagsPreventParsing content=true / work? or is it still necessary? Even MS eventually had to accept it was a bad idea and they removed it before releasing IE6. From http://support.microsoft.com/kb/835564/en-gb The most contentious part of IE6, Smart Tags, was removed just prior to its release. As far as I know they didn't sneak it back in later, either; so the tag shouldn't be necessary :) cheers, Ben -- --- http://www.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
