Re: [WSG] More on understanding html5

[Keryx Web]

2010-01-05 13:59, designer skrev:
> I am getting a bit bogged down with this new stuff!
> I used  in this case:

 is still being discussed and no real decision has benn made. 
The proposal to use dt/dd in fugure and details seem to have been shot 
down and new elements for captioning these are being discussed.


Then again,  and or  might be totally scrapped.

There are other parts of HTML5 that have reached a higher level of 
maturity. One should probably start using them.


BTW. the validator does not change with every spec change. For issues 
like this the best resource to consult is probably HTML5 doctor or the 
WHAT WG help list. (The help list, not the main discussion list.)



--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/



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

Re: [WSG] or CSS3 Border Background

[Keryx Web]

On 2009-08-09 12:48, Stuart Foulstone wrote:

The hr element represents a paragraph-level thematic break, e.g. a
scene change in a story, or a transition to another topic within a
section of a reference book.


Correct, but rarely useful. The only indication given to users is 
visual. I do not think AT-technologies picks it up.



So the decision is  circumstantial, sometime you  use hr, and
sometimes use CSS 3 border background property.


I've not seen a case in a really long while where an hr would be useful, 
except for debugging.



  deprecated in XHTML and the correct mark-up is to use a header
which helps to help define that relationship.


No, it is not. But it is better avoided, as said by many in this thread.


--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/


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

Re: [WSG] My best practice HTML sheet

[Keryx Web]

On 2009-06-26 10:23, michael.brocking...@bt.com wrote:

The link to the PDF version has an extra folder in it, that should not be 
there, the actual link to the PDF is:
http://keryx.se/resources/html-elements.pdf

Regards,
Mike


Forgive my double posting, but just to let yo all know that I've read 
every reply. Mike found out how to cope with my oversight. Links have 
been fixed.



--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/


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

Re: [WSG] My best practice HTML sheet

[Keryx Web]

On 2009-06-26 02:37, Mark Huppert wrote:

This file gives me 482 errors and 6 warnings from
the W3C parser plugin for Firefox. Adobe Acrobat was
unable to parse it.


I got 1008 (using HTML 5 experimental validator) ;-) Now it's zero.

There was a bunch of  that I did not bother to remove until the 
rest was working. It seems as though my CSS-design for Firefox 3.5 works 
though, since there are no complaints.


Time to get it to work in Safari as well then. My technique is described 
at 
http://itpastorn.blogspot.com/2009/05/rotating-column-headers-using-css-only.html


Sidenote: I do not like implicit closing of elements, but removing all 
 would save me more than 5kB of page size... Decisions, decisions.


--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/


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

Re: [WSG] My best practice HTML sheet

[Keryx Web]

On 2009-06-26 01:29, daniel a. thornbury wrote:


Very useful!

...but I would love the PDF or ODT versions to be available so I can
print it up to stick onto the wall for quick-reference (and to make me
look a little smarter)...



Ooops! When I changed the resource name to hide the file extension, I 
forgot to change the path in the links.


Fixed.

--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/


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

[WSG] My best practice HTML sheet

[Keryx Web]

Hello all!

I have updated my best practice table at

http://keryx.se/resources/html-elements/

I've switched from XHTML to HTML and I've added an experimental layout 
with rotated column headers in Firefox 3.5 (JS required, but progressive 
enhancement is used).


Please report any content issues.

Please report any problems in FFox 3.5.

Known issue: The checkmarks (✓) do not work in MSIE or Webkit based 
browsers. It does not make the table less understandable though.


--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/


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

[WSG] Hotlinking prevention does not work

[Keryx Web]

Hi

I looked at my logs today and I saw a lot of hotlinking gping on.

So just why does this code not work?

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^http://(.+\.)?keryx\.se/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /bilder/image-theft.png [L]


Lars Gunther


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

[WSG] WaSP Interact

[Keryx Web]

I hope nobody has missed this:

http://interact.webstandards.org/

"It is with great pleasure that we unveil the WaSP InterAct Curriculum, 
an initiative that aims to unite industry, educators, and practitioners 
with one common goal: to improve the quality of education that the next 
generation of web professionals have available to them."


http://www.webstandards.org/2009/03/16/the-dawn-of-the-education-era/


Lars Gunther


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

Re: [WSG] seeking JavaScript Bible comments

[Keryx Web]

Den 2009-02-09 03:02, Joseph Taylor skrev:

I wouldn't worry about document.write examples too much.
You just need to keep in mind that the book is designed to teach the
language from scratch, and quite possibly the reader hasn't scripted
before.

Starting from point zero, document.write is a good way to get started
learning and making things happen fast. I'll guess that the Bible-series
programming books aren't necessarily considering "standardistas".


An exceptionally late reply, since I've been incredibly busy the last 
month...


The problem with using document.write or some other bad practice in an 
example is that the code tend to be used in real solutions. Students 
(and "real" developers) often search for the first solution that "works".


Simple examples of how to use e.g. a control structure can be 
illustrated using console.log() or the JavaScript shell, even 
window.alert() is preferable.


I taught complete newbies JavaScript last semester. The very first thing 
I did was showing them the console in Firebug. (The computers at school 
do not have Opera or a webkit based browser installed, but I told the 
they have got similar tools.)


Using Firebug for my examples was a huge timesaver when showing how the 
syntax or built in objects work, compared to using any technique that 
relies on document.write. There simply is no need for it any longer.



Lars Gunther


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

Re: [WSG] URL naming best practice guide? [SEC=UNCLASSIFIED]

[Keryx Web]

Chris Vickery skrev:

That's an awesome help. Thanks everyone!

http://googlewebmastercentral.blogspot.com/2008/11/googles-seo-starter-guide.html
http://www.useit.com/alertbox/990321.html
http://www.w3.org/Provider/Style/URI



Morec thoughts:

http://shiflett.org/blog/2007/jan/url-vanity
http://shiflett.org/blog/2008/mar/urls-can-be-beautiful


Lars Gunther


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

Re: [WSG] seeking JavaScript Bible comments

[Keryx Web]

Paul Novitski skrev:
I would love to get your critical comments on Danny Goodman's JavaScript 
Bible

http://ca.wiley.com/WileyCDA/WileyTitle/productCd-0470069163.html

I'm updating the book to its 7th edition and am making some significant 
changes, including upgrading it to include separation of layers & 
progressive enhancement.


OK. You are addressing my biggest gripe. I'm sure you will get the word 
"unobtrusive" in there as well!


JQuery has just demonstrated that even a library can be built using no 
browser sniffing at all. Capability testing a.k.a. feature detection and 
the new kid on the block, bug detection, really takes a lot of focus 
away from the compatibility tables.


Do you have any other criticisms of the book, either minor or major, 
that I should consider in the rewrite?  I would be grateful for your 
detailed remarks.


I am developing the DOM Scripting courses for the Web Standards Projects 
Educational Fask Force. High on my personal wish list is a chapter on 
JavaScript from an academic, computer science, perspective.


Also, the first examples of JavaScript tend to use document.write when 
illustrating the simplest parts of the language. Usage of document.write 
should be banned from day one. Encourage the readers to test simple 
stuff in a console (e.g. Firebug) or the JS-shell instead. (Appendix C)


Namespacing (or the lack thereof) is another issue that should be 
addressed early on. As soon as example code becomes realistic, it should 
be enclosed in a self executing function or in some other way be hidden 
from the global scope.


ECMAScript 3.1 is coming along soon(?). It warrants a discussion.

ES 3.1 will have built in functionality for JSON. JSON is missing in the 
6th edition *entirely*.



Lars Gunther


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

Re: [WSG] JavaScript clarification please - let blocks

[Keryx Web]

Brett Patterson skrev:
I like that explanation. I get it now. Thanks. One more quick question 
though, what is a let-block, in general? Thanks. That really does make 
it a lot easier to understand.


Brett


Normally JavaScript does not have block scope.

var foo = 1;
{
foo = 2;
}
alert(foo); // will give you 2

Let-blocks will provide block-scope on an opt in basis:

var foo = 1;
{
let foo = 2;
alert(foo); // 2
let bar = 3;
}
alert(foo); // 1
alert(bar); // undefined

Block scope is one feature that makes it easy to write interoperable 
code. My variables won't mess with your variables. Today we use function 
scope to accomplish the same thing:


var foo = 1;
(function() {
var foo = 2;
alert(foo); // 2
})() // last parenthesis invokes anonymous function
alert(foo); // 1


Let blocks are really handy in for loops:

var i = "Hi there";
for ( let i = 0; i < 10; i++) {
alert(i); // 0 - 9
}
alert(i); // "Hi there"

Self executing functions have another kind of power through closures and 
possible return values, so the two do not completely overlap.


More info on the "New in JavaScript 1.7" article on MDC.


Lars Gunther



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

Re: [WSG] Javascript classical inheritence [was: JavaScript clarification please]

[Keryx Web]

Mathew Robertson skrev:

All this talk over JavaScript not supporting classes, is incorrect. I put together a 
little demo of classical "class-based" inheritence.

The only real limitation is that you can't do "protected members" and "friends" 
and the syntax might be considered to be a little clunky.

http://members.optusnet.com.au/~mathew/js/


Liorean has already provided clarification on the difference between 
supporting class-based inheritance through emulation, vz. having native 
support.


I would like to point out that John Resig writes about this topic in hos 
book Pro JavaScript Techniques, and that it is implemented in one form 
or another in many libraries.


There was also an effort to support the now canceled ECMAScript 4 syntax 
in older browsers, Mascara, that included support for classes. 
http://ecmascript4.com/ I suppose its status is uncertain.


In short, as MR shows: If you feel intimidated by prototypal 
inheritance, there are tools available to make JavaScript behave in a 
fashion that is more suited to your tastes. :-)



Lars Gunther


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

Re: [WSG] JavaScript clarification please - object methods are properties

[Keryx Web]

Keryx Web skrev:
JavaScript has no pure hash-tables, aka associative arrays. Object 
properties can be used to emulate associative arrays, though. A PHP 
programmer will feel very limited, though.


A JavaScript object *is* not an array ...
It can have methods as well as properties.



Nitpicking on myself. JavaScript makes no real distinction between a 
property value that is a function (and therefore becomes an object 
method) and property values that simply store a simple type. i.e. a 
method *is* a property, that stores a function, which is possible since 
they are "first class objects".




Lars Gunther


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

Re: [WSG] JavaScript clarification please - versions

[Keryx Web]

Brett Patterson skrev:
I am sorry, but I must ask. Are you saying that the term JavaScript is 
owned by Sun? Or just the Java part? And, yes, JavaScript is implemented 
in Internet Explorer.




I see that your question has already been answered. I will give some 
additional points.


Mocha was Brendan Eich's internal name during initial development at 
Netscape. It was renamed LiveScript by him and his fellow enginers, but 
changed to JavaScript by the *marketing* department.


JScript in MSIE 6 and 7 is *roughly* comparable to JavaScript 1.2 and to 
ECMAScript 3.0.


There is a document, produced by MS, that in very high detail outlines 
how JScript, and other browsers JS engines, differs from the spec. It is 
available at https://developer.mozilla.org/en/JavaScript


The JavaScript support in Safari, Google Chrome and Opera is *roughly* 
comparable to JavaScript 1.5, and some parts of JavaScript 1.6.


(Note: 99 % of the time when one curses the differences between 
browsers, it is not because of their deviations from each other in 
Java/J/EcmaScript, but how they differ from each other on the DOM.)


Mozilla is allowed by the ECMAScript spec to develop JavaScript as a 
superset to ECMAScript, and indeed they have. JavaScript 1.8 contains 
quite a few features that (probably) will not even make it into 
ECMAScript 3.1 (generators, iterators, let-blocks - personally I really 
like let blocks!).


A few years ago Netscape proposed a JavaScript 2.0 version. Many 
features from that proposal has made it into ActionScript and into 
JScript.NET (used on the server). ECMAScript 4.0 that was being worked 
upon altered from the original JS 2.0 proposal in some ways. That work 
has however been halted. One group, led by Mozilla and Adobe, wanted to 
*add* to ECMAScript in radical ways. One group, led by MS and Yahoo 
(Doug Crockford), wanted primarily a *subset*, getting rid of "the bad 
parts". They soon added features, though, and the language was in 
essence forked.


A compromise has been reached. "ECMAScript Harmony" will most probably 
be released as version 4, but not for a couple of years. And it will 
differ from the ES 4 proposal as stood in June.


It is the intention of the EcmaScript working group to release ES 3.1 
next year, at which time they hope to have two interoperable and 
complete implementations. One will most probably be SpiderMonkey 
(Mozilla) and the other might be V8.


The new ES 4, i.e. "Harmony", will probably not see the light of day 
until 2010 or 2011.



Lars Gunther


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

Re: [WSG] JavaScript clarification please

[Keryx Web]

Anthony Ziebell skrev:
Still confuses me though - if someone is object-orientated but is in 
essence prototype-based (with regards to object, inheritance, etc), why 
is it incorrect to say JavaScript is prototype-based?




Your confusion comes from comparing apples to steam trains.

Prototypes are an inheritance mechanism for objects.

Classes are another inheritance mechanism.

A language may implement either one or both (very rare).

It does not matter which inheritance mechanism that is used. It is still 
an OO language.


It is *not* incorrect to say JavaScript is prototype based. It is. No 
one is denying it.


It is *not* incorrect to say JavaScript is OO. It is, since OO is a 
paradigm for programming which JS fits very neatly in. It is de facto 
called OO in the ECMAScript spec.


It is *not* incorrect to say JavaScript is object based. It is - since 
it has object wrappers for all primitive values.


You really did seem to say that classes are needed for a language to be 
called OO. Now you have stated that you did not intend to say that. Case 
closed.



Lars Gunther


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

Re: [WSG] JavaScript clarification please

[Keryx Web]

Brett Patterson skrev:
> I am in the middle of a conversation with this guy who says that 
JavaScript is an object-oriented language. Is he correct? Could you 
please site some references?


I have read the whole thread up until now, but will answer your starting 
message, since I am not addressing a single specific respondent.


I am in charge of developing DOM Scripting courses for the Curriculum 
Framework of the WaSP Education Task Force[1]


I have therefore tried to read every single resource about JavaScript, 
ECMAScript and the DOM that has been written from a computer science 
perspective. There are not that many, which might be a reason behind the 
confusion.


Anyway: JavaScript (a term owned by Sun, licensed to Mozilla, and used 
by all browser vendors but Microsoft) is in all essence, as Liorean has 
stated, a superset of ECMAScript 3.0. That is also the sentiment of 
Brendan Eich - and should therefore be taken as a final word. (Anthony 
was indeed wrong about this.) JScript as implemented in Internet 
Explorer is roughly equivalent, but deviates in some small ways.


JavaScript is a mix of Self, Scheme and C (according to the ECMAScript 
3.1 draft, the "love child between Scheme and C" according to Brendan Eich).


JavaScript is indeed Object Oriented, but even though every script is 
run within a host object - usually the window object of a browser - a 
procedural style is possible to use. 90's DHTML scripts were usually 
procedural and used document.write (which is not ECMAScript but part of 
the DOM) in a way that reminds me of *standard streams*, which could be 
provided by the host object, but usually aren't.


Public, private and protected methods and properties are not easily 
implemented. Object Oriented design patterns (singletons, factories, 
registry, adaptors...) can usually be emulated. Sometimes this is only 
done through considerable wizardry using concepts like lambda and closures.


ECMAScript 4.0 aka JavaScript 2.0 was supposed to get a limited class 
based inheritance mechanism to *complement* the prototype based one we 
use today. Those plans have been halted. ECMAScript "Harmony" will most 
probably *not* get any class based inheritance.


(At least two JavaScript engines (V8 and Squirrelfish Extreme) emulate 
class based object creation as part of their just in time compilation, 
but that really is a compiler issue.)


ECMASCript 3.1 will get a few new methods to facilitate easier 
inheritance patterns. E.g. Object.freeze(). Many popular libraries also 
have methods that facilitate OO-patterns.


As old school cut' n' paste coding is getting superseded by libraries 
procedural code is becoming less seen and OO-style coding is getting 
more used.


Indeed, using object chaining in JQuery et al, the programming is even 
well on its way to become *declarative*.


Summary:

1. JavaScript *is* OO.
2. JavaScript uses a prototypal - class-less - inheritance mechanism.
3. Anyone writing a script can use procedural style, OO-style or even 
make forays into a declarative style.


Nit picking on some stuff in the thread:

JavaScript has no pure hash-tables, aka associative arrays. Object 
properties can be used to emulate associative arrays, though. A PHP 
programmer will feel very limited, though.


A JavaScript object *is* not an array (once again Anthony got it wrong). 
It can have methods as well as properties. Arrays are however 
objects, and confusingly


typeof [ 1, 2 ]

evalutes to "object", not "array". A major design flaw.

The best known way to test for an array is:

Object.prototype.toString.apply(value) === '[object Array]'

Discovered by Mark Miller of Google.

From a very strict computer science point of view averything in 
JavaScript is *not* an object. (No matter how much Alex "Dojo" Russel et 
al. reiterates that mantra.) In practice everything is. JavaScript has 
got a few "primitives" (numbers, strings, booleans, undefined). Whenever 
a primitive is referenced with an OO-syntax it is converted into its 
corresponding wrapper object. This was modeled after Java according to 
Brendan, and he has stated that it probably was a bad idea. (Search the 
ES4 mailing list for a reference.)



Lars Gunther

Sources:

MDC, including https://developer.mozilla.org/En/About_JavaScript
ES 3.0 spec
ES 3.1 spec draft
"JavaScript, The Definitive Guide" (latest edition)
ES3.1 mailing list
ES 4/Harmony mailing list
Doug Crockfords site and book ("JavaScript, the good parts")
Numerous other JavaScript books

1. 
http://www.webstandards.org/2008/07/31/announcing-the-wasp-curriculum-framework/




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

Re: [WSG] Learning Javascript properly

[Keryx Web]

Simon skrev:

Hi all,

I really want to get stuck in and learn Javascript properly,


Learn the basics first - then libraries:
http://www.456bereastreet.com/archive/200701/learn_javascript_before_tasting_the_library_koolaid/

Mozilla Developer Central is a nice resource.

All Sitepoint books are great as well. PPK's books i also very good.


Lars Gunther


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

Re: [WSG] Chrome JavaScript features - not speed

[Keryx Web]

Breton Slivka skrev:
>> - Array and string generics
>
> You can apply array functions to strings, if that's what you mean.
>

And vice versa

>> - Expression closures
>
> I don't know how you could have javascript without those. Pretty much
> every website would break. Event handlers would be impossible.

I mean the shorthand for function definitions in JavaScript 1.8:

function(x) x * x
   <=>
function(x) { return x * x; }

http://ejohn.org/blog/javascript-18-progress/

From your writing it seems they are at 1.6 in their features, like 
Opera and Safari, but ahead of MSIE 7 (I have not checked MSIE 8 for 
this either).



Many thanks for your report!

Lars Gunther



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

[WSG] Chrome JavaScript features - not speed

[Keryx Web]

Concerning Chrome, I have some unanswered questions about V8.

Exactly what JavaScript features does it support? (This is NOT a 
question about it's speed.)


The release statememt simply says that it follows the EcmaScript 3.0 
standard, but we all know that it is quirky in places and that current 
browsers deviate from it in some of those. With Mozilla leading the pack 
and Opera and Webkit/Squirrelfish following closely, there also are a 
slew of additions, a.k.a. JavaScript 1.6, 1.7, 1.8, etc.


Has anyone tested if V8 supports things like:
- Array extras
- Getters and setters
- Array and string generics
- Generators and iterators
- Expression closures
- Array comprehensions
- Block scope with let
Etc


Lars Gunther

(No I've not had the time to test myself)


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

Re: [WSG] Google chrome... Accessibility coming very soon???

[Keryx Web]

Adam Martin skrev:
Hey guys... it is great that talk about accessibility and chrome has 
been raised - but I do think that we need to wait until it is out of beta.


A beta is supposed to be feature complete. otherwoise it's an alpha.


Lars Gunther


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

[WSG] Mobile graded browser support

[Keryx Web]

All right. I will stop complaining about "designing for the iPhone" and 
try to attack this from a positive angle.


How can we go about making our mobile websites according to sound 
principles. Bearing in mind that mobile browsers often lack the features 
we wish they had. Borrowing the terminology from Yahoo:


- What is the current baseline of A-grade browser capabilities?
- What browsers should receive A-grade support?
- How do we on purpose disable CSS and/or JS for our C-grade browsers?
- Should we perhaps have A-grade (Safari, Opera, Fennec and ?) and 
B-grade (MSIE Mobile, Netfront, Blackberry, Dillo, Obigo???)

- And perhaps A- (for devices without a pointer and cursor)?

Oh, and while we are at it, check this out: 
http://www.w3.org/WAI/mobile/experiences-new



Lars Gunther


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

Re: [WSG] iphone should not be part of your url

[Keryx Web]

Ted Drake skrev:

Slightly off topic...
There is a really good Wordpress template/plugin that detects the very
specific user-agent for iphone and touch and changes your theme to an iphone
specific layout. 


There is a plethora of such solutions covering most major 
PHP-frameworks, RoR, etc. That is the really scaring part! However, I 
suspected that most people on this list would stay away from that 
solution. I thought that on this list that would be well understood by now.


Then I saw that even so called standrads aware developers started to use 
"iphone" as part of the URL instead, which IMO is perheps less evil. But 
only by a few degrees.



Sure, it's arguable if you should design for a particular appliance.
However, they've done the work for you and it works great, although a bit
generic in look and feel. You can always make adjustments to the theme for
personalization.


No it is not "arguable". Within the web standards aware community this 
argument has been settled!


Come on people. Can't you see that this is *EXACTLY* the arguments ´that 
were used in 1998 when people forked their code for MSIE and Netscape? 
It "worked". It really did. In the short term.


Developing with the iPhone in mind (not "for" the iPhone) really should 
mean nothing else than what it means to develop with e.g. Firefox 3.0 or 
Opera 9.5 in mind. You can take advantage of the advanced features, if 
you use them as progressive enhancement and capability test for them.


The only hard question is how you deal with what's *lacking* in the 
iPhone: A cursor and a pointer!


Ohh, it's from Apple, it's shiny, it has no buttons - what is 10 years 
of hard fought struggle for web standards worth in that perspective? 
Zilch. It seems.



Lars Gunther


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

Re: [WSG] iphone should not be part of your url

[Keryx Web]

Ben Dodson skrev:
I don't personally have a problem with having iphone in a URL as it is 
generally used for applications that are very specific to the iphone.


It is 1998 and I am developing an application that is very specific to 
MSIE... A strategy proved bad!


IMO this is *exactly* the reasoning that J. Zeldman, Steve Champeon et 
al protested against. A protest that started and defined the web 
standards movement.


Yes, perhaps there should be versions for other devices (e.g. Nokia) but 
the reality is that most developers won't bother making specific sites 
for these users and instead use a generic mobile stylesheet.


No there should not be versions for Nokias or Sony-E's or LG's or any 
other device. What we perhaps need, though, is a graded browser support 
chart, like Yahoo has for desktop apps.


The 
difference with the iPhone is that it's the latest bandwagon in town and 
that the majority of iPhone owners will use the internet on the phone 
(whereas the majority of Nokia phone owners won't use the web browser on 
the phone).


The difference is that Nokia et al makes several different kinds of 
phones, not all are smartphones. Every single smartphone owner I know 
uses the web browser on the phone and has been doing it for quite a few 
years.


It is great that the iPhone has made people aware of the mobile web, and 
lowered the threshold for some to use it. But as developers we should 
not care about the present, but the present and the future! Locking 
ourselves in to one device is not a strategy for the future, even if 
iPhone shows up as the leading mobile device in usage stats today. 
Remember, there once was a time when MSIE was so dominant that as a web 
developer it made sense in many ways to develop MSIE only web sites!


It also has a very specific style and so companies will try 
and cater to this (e.g. the facebook web app was designed to look like a 
native iPhone application).


That I predict is a fad that will quickly go away. Site owners will soon 
see the benefits of designing for the brand of the website, rather than 
the brand of the device it is accessed from.


Of course, now there is the App store and the ability to run third party 
applications, I'm sure a lot of these iPhone specific websites will 
disappear as the developers move to offering a built in solution.


Hopefully you are right. Off topic: The fact that people will jubilantly 
welcome a solution that means they are getting locked in to a single 
vendor is also beyond my understanding...


And I am not a Mac hater. I use Macs (as well as Windows and Linux) and 
listen with delight to my iPod.



Lars Gunter


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

Re: [WSG] iphone should not be part of your url

[Keryx Web]

Svip skrev:

I see where you're coming from, but let's not forget that the iPhone's
browser is (as of right now) the largest mobile browser, in the
fashion, that it is basically the same browser you get on your
computer.


The good thing about the iPhone is that suddenly USA is getting to know 
the mobile web. The bad thing is that USA seems to believe that the 
mobile web = iPhone.


In Scandinavia, where I live, most people are *not* that impressed with 
the iPhone, nor is it "the largest mobile browser". We have been surfing 
the web on our 3G phones for quite some time now. But we welcome all 
(US) Americans to the 21st century!



Lars Gunther
(who probably will get himself a Nokia N96 when it comes out, and even 
today would take an N95 over the iPhone)



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

Re: [WSG] iphone should not be part of your url

[Keryx Web]

Matthew Pennell skrev:


To that end, you either sniff for devices and/or serve mobile content on 
a different URL.


Yes, but if "iphone" is part of your URL, what does that say to people 
using Nokia, Sony-E, LG or any other smartphone? And what about Opera 
Mini, Opera Mobile, MSIE Mobile (OK forget that one) and Fennec?


Designing - with reduced content - for small screens? Yes!

Take into consideration that Safari on the iPhone lacks a cursor (you 
can't even select text, I've been told!) and a pointer (which is a 
"feature", not a bug...) Yes.


Designing for specific devices - including naming your URL? No!



Lars Gunther


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

[WSG] iphone should not be part of your url

[Keryx Web]

I am feeling moody today, but...

Are we selling our soul for a shiny newish toy from Apple?

A specific app or device should not be part of an URL. Period.

URL's like iphone.domain.com are an abomination! Even if the content is 
standards based.



Lars Gunther


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

CSS selectors in FFox 3.1 Was: [WSG] Mixing CSS3 and CSS2

[Keryx Web]

Keryx Web skrev:

Correction: Two errors in FFox 3.1a1pre:

http://www.glazman.org/weblog/dotclear/index.php?post/2008/06/06/CSS-3-Selectors-test-4 


Now (probably) fixed!

https://bugzilla.mozilla.org/show_bug.cgi?id=420245 (See comment 17 and 
onwards)



Lars Gunther


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

Re: [WSG] Mixing CSS3 and CSS2

[Keryx Web]

Keryx Web skrev:
(See also D Glazmans test: Six errors in Safari 3.1, one in FFox 3.1 
version of Minefield, **zero** in Opera 9.5 beta, build 10048. I have 
not tested nightly Webkit.)


Correction: Two errors in FFox 3.1a1pre:

http://www.glazman.org/weblog/dotclear/index.php?post/2008/06/06/CSS-3-Selectors-test-4


Lars Gunther


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

[WSG] Thoughts on CSSDoc

[Keryx Web]

Hi

As a PHP developer I expect myself and fellow programmers to use PHPDoc 
for every single file/class/function/etc they will ever write. It has 
become non-negotiable.


Most programming languages have their own implementation of this now, 
all in honor of JavaDoc, who invented the system.


Some JavaScript projects (e.g. YUI) use JSDoc, many don't.

But what about CSSDoc. http://cssdoc.net/

Any users?

Any thoughts?


Lars Gunther


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

Re: [WSG] Mixing CSS3 and CSS2

[Keryx Web]

Rahul Gonsalves skrev:


#foo {
  border: 1px solid fuscia;
  -moz-border-radius: 0.5em;
  -webkit-border-radius: 0.5em;
  border-radius: 0.5em;
}

This will ensure that browsers like IE6/IE7 only see the first line 
(border...) and draw a straight box around #foo. Slightly smarter 
browsers like Camino/Firefox 2/Safari 2 will get the the engine-specific 
rules (-moz/-webkit) and all CSS3-supporting browsers (Safari3, 
Firefox3, IE8(?) etc) get the last line and give you a pretty rounded 
corner.



Good advice, but a bit optimistic about the implementations.

Firefox 3.0 does not support "border-radius", perhaps in Firefox 3.1. 
[1]. There are still at least one unsettled issue in the spec (proposed 
soultion in editors draft).[2] However, unsolved implementation issues 
when combined with gradients and non-solid borders, seem to be fixed 
from in FFox 3.[3]


Safari 3.1 does not support border-radius without the -webkit prefix.

Here is a nice test from webkit's bugzilla (using prefixes for both 
webkit and moz): https://bugs.webkit.org/attachment.cgi?id=8633


Try it in both FFox 3 and Safari 3.1 and you'll see some 
inconsistencies. Enough to drive a designer crazy.


Both Webkit and Gecko use the Cairo library (except on Mac OS), so their 
rendering will probably be very close to each other in the future.


MSIE 8 is supposed to get full CSS 2.1 support. CSS 3 is not really on 
the table, according to the announcements. Now that a lot of modules 
have moved much closer to REC-status the pressure to implement them is 
of course higher.


There is a a ton of goodness coming up in FFox 3, including full support 
for CSS 3 selectors, media queries, HTML 5 audio and video, etc. I am 
actually looking more forward to 3.1 than 3.0 as a developer. (But I 
can't live without the awesomebar, so as a user 3.0 is great...)


Lars Gunther


1. https://bugzilla.mozilla.org/show_bug.cgi?id=431176
2. http://dev.w3.org/csswg/css3-background/#the-border-radius
3. Compare this page in FFox 2 and FFox 3: 
http://ne.keryx.se/cssdemo/testa_css3.php

4. http://www.css3.info/firefox-31-is-the-latest-to-pass-our-selectors-test/
(See also D Glazmans test: Six errors in Safari 3.1, one in FFox 3.1 
version of Minefield, **zero** in Opera 9.5 beta, build 10048. I have 
not tested nightly Webkit.)



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

Re: [WSG] PHP Standards

[Keryx Web]

Ian Chamberlain skrev:
Fingers crossed this is not too far off topic; being a newby to PHP; any 
clues where I can find how-to's, snippets, libraries or even application 
suites built from PHP that are built to a good minimum standard please.


I am guessing that PHP is much like JavaScript in that a lot of what is 
floating about is either poor or pooh the result of all the good programmes 
stending their time on ASP or J2EE.


There is no "standard" for PHP, but there are best practices. And they 
mimick what's happening on the client.


Client: Separation of concerns between design, content and behavior.
Server: Separation of concern between different kinds of logic.

The number one priority having grasped the basics of the language would 
be to separate presentation logic from business logic, the second to 
separate business logic from data storage logic. When you evolve as a 
developer you may have even more tiers.


Some people like to call this MVC. However, the web and PHP are ill 
suited for *pure* MVC implementations. But PHP has never been about 
purity...


Another thing they have in common. Frameworks ar good, but not something 
you can use to avoid learning the language 
http://www.456bereastreet.com/archive/200701/learn_javascript_before_tasting_the_library_koolaid/


A third thing in common: All devs should agree on a style guide! Naming 
conventions, indentation, bracket placement, etc.


A few more notes:
PHPDoc is something that should be picked up ASAP. I teach it to newbies.

Read the manual and search it thoroughly. The strength of PHP are the 
numerous built in functions. Replication of built in functions in 
userland PHP code is a waste of time, CPU cycles and makes the code bloated.


And PHP 4 really is dying. PHP 5 is faster and has a ton of goodies. Do 
not bother with PHP 4 any more!


Good books:
Learning PHP
PHP 5 Unleashed
PHP Power Programming
Advanced PHP Programming


Lars Gunther


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

Re: [WSG] Torrents of em and strong abuse (Was: Re: WSG Digest)

[Keryx Web]

Justin Sinclair skrev:

Are there really torrents of  and  abuse out in the real world?


I've been guilty of that sin in the past myself.

I think the torrent was stemmed while still a creek - if that saying 
works in English.


One might argue that it is possible to get such an impression 
in this lesson: http://www.youtube.com/watch?v=a0qMe7Z3EYg


I love it, though! 99 % is head on.


Lars Gunther


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

Re: [WSG] u, i, strong, em and I18N/L10N. (Was: Why is deprecated?)

[Keryx Web]

Andrew Cunningham skrev:

although i'd go further and say that browsers implementing italic as 
default presentation for  and bold as default presentation for 
 are also wrong. Its attempting to make the typographic 
conventions of the Latin and Cyrillic scripts universal when they aren't.


Its poor internationalization.


Not sure what you are saying here? A sigh over a bad decision in the 
past or do you actually want to change the current default 
implementation? Into what?


Yes, bold and italics for  and  is Western centric, bit 
having no default styling would make a lot of people very perplexed if 
it changed now.


Most problems with default styling of  and  seem solvable 
with :lang (Not that all current browsers support it perfectly, though.)


 and  have no universal meaning. They have no universal 
applicability. They are limited to certain typographic traditions and 
certain scripts.


Agreed, but it is still a common use case to have people discussing in 
English, German, French (or Swedish)! Should we remove the possibility 
to do so. There are like a quadrizillion pages on Wikipedia in western 
languages. Editors create bold text like '''this''' and italics like 
''this''. 99 % are absolutely clueless about semantic HTML. Turning 
'''this''' into this seem to be the least damaging way to handle 
such editors.



 > As the HTML 5 standards stands today, this is the view of the working
 > group as well. The standard will provide some additional use cases where
 >  and  perhaps should be considered the best (or least sucky)
 > option available.

And what about cases where it should never be used?


Once again, the HTML 5 spec clearly discourages using  and  for 
many uses where it has been used traditionally. I am not sure what you 
are getting at. It does not encourage frivolous use of  or .


using  and  implies that you have bold, italic and bold-italic 
fonts to display the text with. On a standard Windows install for 
instance, how many scripts actually do have such fonts compared to the 
scripts that don't have these fonts?


In the western world I'd suppose 100 %... If I want a site in Swedish, 
why should i not use a technology just because it would not work in 
Japan? Perhaps you are not arguing against me, but is kind of feels like 
you think I am encouraging arbitrary use of visual markup regardless of 
context.



I'd add never use  and  when content needs to be internationalized.


Do not apply default presentation to semantic elements when content is 
to be internationalized.


I'd use it as part of an applicable localization. Not as part of a 
template that will or might be be translated into non western languages.



 > * CMS software and an editor that can not access predefined classes
 > should prefer  and  over inline styles.

Such a CMS and editor is poorly internationalized and has limited scope.


A lot of websites have limited scope. You will most probably never see 
http://keryx.se translated into Japanese or Thai. So if I develop a CMS 
for my own website, am I *required* to make it usable in any part of the 
world? (OTOH, If I was working on ibm.com I'd have to think about it all 
the time.)


In summary: I cant see that we actually disagree and I do think you have 
valid points in bringing up I18N issues. Our non-western friends on this 
list could perhaps chip in and provide additional wisdom.



Lars Gunther


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

Re: [WSG] Why is deprecated?

[Keryx Web]

Kepler Gelotte skrev:

Hi,

I am just curious if anyone can explain why the  tag has been deprecated
while  and  are still allowed.


Summary (most things have been said already):

Underlines on paper have no usability impact, since you cant click on 
it! Underlines on web pages have a usability impact, since people think 
they are clickable links.


Underlines on paper printed with a typewriter existed because it took a 
great while until bold fonts or italics came around - and even when they 
did you had to manually change the ball in your typewriter. Today 
italics and bolding - as well as changing font size - exist and are more 
 aesthetically pleasing alternatives.


One should not think that conventions from print - or typewriters - 
apply on the web. The web has its own conventions.


On the web, the convention is that links are blue (when not visited) and 
underlined. Change one with care, change both with extreme care. The 
main place where you can change this convention is in menus, where there 
exist other visual clues to guide the user.


This means that there is no valid use case left for .

Although most cases where one could have used  or  can be replaced 
with CSS, , ,  or a header, there are still some use 
cases left.


E.g. on forum software you may want to allow some styling. Abusing  
and  for styling purposes is worse than using  and  for 
emphasis. Semantic meaning that has been left out is a lesser evil than 
semantic meaning that is misused.


Abusing  just for italics or  just for bolding, when no 
emphasis is intended is the same *sort of* abuse as using tables for 
layout. It is only abuse of a slightly lesser degree.


 and  are actually lesser evils than inline styles, which may be 
the only option left if they are removed. They are less bloated and way 
easier to handle from a programming point of view.


As the HTML 5 standards stands today, this is the view of the working 
group as well. The standard will provide some additional use cases where 
 and  perhaps should be considered the best (or least sucky) 
option available.


http://www.whatwg.org/specs/web-apps/current-work/#the-i
http://www.whatwg.org/specs/web-apps/current-work/#the-b

This means (summary of my summary):

1. A. Never use  and  when there is a usable element with semantic 
meaning.


1. B. But do *not* use semantic elements outside of their defined 
meaning, which is even worse.


2. A. If possible use CSS. This means that web designers, who may do 
stuff like editing the sites main CSS files, should use clever selectors 
and semantically significant class names (like , not class="italics">) to achieve bolding and italics.


2. B. If possible, avoid using inline CSS. This means CMS software 
should provide access to (a subset of) the designers classes - and 
content providers be taught how to use them. WYSIWYG editors are often 
the bane of good markup. If one has to chose between inline CSS and  
or , use the elements.


Summary of my summary of my summary:

* A web developer should never use  and .

* CMS software and an editor that can not access predefined classes 
should prefer  and  over inline styles.


When googling to provide some additional info I found this, and since he 
agrees with me it must be a fine resource: 
http://green-beast.com/blog/?p=222


(I do however believe there is a use case for the  element - until 
recently called .)



Lars Gunter


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

Re: [WSG] and in lists

[Keryx Web]

Thomas Thomassen skrev:

Thanks. Got a link to where I can follow that incase there's response?



http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014252.html

There have been two responses so far. One wishing to expand the 
suggestion and one that is simply positive. No word from Ian yet.



Lars Gunther



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

Re: [WSG] and in lists

[Keryx Web]

Thomas Thomassen skrev:

I posted a comment about it in the W3C public HTML discussion group, 
hoping it'd be picked up and amend HTML5's specification to allow this. 
However, there's yet been any response. Is there any other place I could 
air this issue in hope of it getting heards by the authors of the next 
HTML specs?


I have sent a copy of your original message to the WHATWG list. Let's 
see if they are more alert.



Lars Gunther


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

Re: [WSG] Apply ALT tag to background image?

[Keryx Web]

Kristine Cummins skrev:

I’ve got a background graphic designated in my style sheet


Backgrounds are decorative and do not need alt *attributes*. Therefore 
CSS does not have a way of providing alternate text.


If it is part of the content and should be "seen" by search engine bots 
and screen readers, it should be put in your (X)HTML.



Lars Gunther


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

Re: [WSG] Web Standards in India

[Keryx Web]

Amrinder Sandhu skrev:

Hello Friends

I am a web standard designer from India where there is very less 
awareness about terms like Web Standards, Usability, Accessibility  and 
User experience


Perhaps you could contact Navjot Pawera, Web Standards Project 
International Liaison in India?


http://www.webstandards.org/action/ilg/members/

http://www.navjotpawera.com/


Lars Gunther


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

Re: [WSG] and in lists

[Keryx Web]

Thomas Thomassen skrev:
I posted a comment about it in the W3C public HTML discussion group, 
hoping it'd be picked up and amend HTML5's specification to allow this. 
However, there's yet been any response. Is there any other place I could 
air this issue in hope of it getting heards by the authors of the next 
HTML specs?




This could also be solved if CSS allowed us to use a "has content" 
selector, i.e. select all LI elements that has only got DEL elements (or 
whitespace) as child elements. I know this issue has been discussed by 
the CSS WG. However, I agree that this is a content issue, rather than a 
styling issue.


I would be very surprised though, if Ian H has not *read* your 
suggestion. Some replies come a bit late, in my experience.



Lars Gunther


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

Re: [WSG] Fieldsets outside of forms. Was: Safari 3.1 and webkit-border-radius

[Keryx Web]

tee skrev:
Perhaps it will help the web standards if W3C to be more authoritative 
and dictatorial?


"MUST NOT", "MUST", "ABSOLUTELY NOT", "ILLEGAL TO USE", "NOT ALLOWED"

to replace these ambiguous "MAY NOT", "SHOULD", "SHOULD NOT".


If one reads the specs these words are not ambiguous. W3C uses these 
words according to RFC2119: http://rfc.net/rfc2119.html (While typing 
this message I see that Thomas Thomassen already has referred to this RFC.)


What is ambiguous is that some older specs do not provide enough detail. 
HTML 4.01 only works since browsers emulate each other.


As for fieldsets outside of forms we have a grey area. No spec says they 
 are allowed or disallowed. There are simply no "SHOULD" or "SHOULD 
NOT", "MAY" or "MAY NOT" phrases to guide us.


That means - in spec language - that there is no prohibition. The only 
place where we have any indication is the DTD. Which says it is allowed.


One could counter that argument by saying that this is a limitation of 
the DTD-language as such. The people who made the DTD cut a few corners 
to not make it too burdensome. However, putting FIELDSET outside of




would not be rocket science. It is doable. All it would take is to 
change this line:




Into this:

form -->


Ergo: The only reasonable conclusion is that the spec writers did not 
intend to forbid the usage of fieldsets outside of forms.


Which leaves with the question if it is wise, i.e. good practice. 
Perhaps also the letter of the law vs. the spirit of the law.


However, the comparison that was made with using tables for layout does 
not make sense. I also note that no one is quoting any research showing 
any negative effects.



Keryx's point of view seems to be dominant, I fear. Even the teacher
at my web design class seems to think that using EMs to style citations
is valid. Yet she generally encourages web standards...   :(


There is a difference. EM has clear implications for screen readers and 
othe UAs, and there are already elements available that has been made 
for quotations:  and .


Once again the comparison is wrong. The two cases are not analogous.

What I want is more like a div with a caption, for which there is no 
predefined markup. In HTML 5 I would perhaps use , but still have 
no way of specifying a caption. Unless HTML 5 explicitly allows the use 
of fieldsets outside of forms, or captions outside of tables (or invents 
some new markup), and specifically defines how the parsing algorithm 
should look like and how the information should be made available to the 
user by the UA.



Lars Gunther


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

Re: [WSG] Fieldsets outside of forms. Was: Safari 3.1 and webkit-border-radius

[Keryx Web]

David Dorward skrev:

 From the spec:
The FIELDSET element allows authors to group thematically related 
controls and labels.  ---


As I said, I am no minimalist. And yes, I have read the spec. It does 
not forbid me to use fieldsets outside of forms. Specs use the language 
of "MAY NOT", "SHOULD", "SHOULD NOT", etc for such scenarios.


I do not wish to enforce my interpretation upon anyone. If someone is 
more of a minimalist in this case than I am - more power to ya! I don't 
mind.



D. It works and has no negative effects that I am aware of.


It has the same negative effects as using tables for layout.


Nope, I can't see that. Tables for layout means that I lose separation 
of concerns. I need to change my HTML-code if I want to rearrange stuff. 
My two fieldsets are no harder to move around than a div.


If I do not wish to use fieldsets anymore, there are only three or four 
small changes to make in my templates for the entire site.


Likewise, tables can produce an effect for screen readers where they 
constantly hear "table start", "table row", "table cell", etc. That 
would be annoying, distracting and confusing. I can't see that my two 
fieldsets would be any such thing, nor have I seen any research that 
claims that to be the case. If someone knows of such research that I've 
missed, I am more than willing to change my mind.



E. I wanted the effect...


Effects are the realm of CSS and JS, not markup.


Generally true, but for me not worth the trouble in this case. Default 
styling of an element (this particular effect I wanted) can be an ally.




Lars Gunther


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

Re: [WSG] Safari 3.1 and webkit-border-radius

[Keryx Web]

tee skrev:


I thought fieldset (with legend) are used only for form elements, I am 
curious why you would used it in your right column's content.




A. It is valid. You may use it according to the DTD.

B. It is being used for grouping of content.

C. I am not a minimalist in interpreting specs. It was developed for 
forms, but I have not seen that you SHOULD NOT use it outside of forms, 
i.e. it is not verboten.


D. It works and has no negative effects that I am aware of.

E. I wanted the effect...


Lars Gunter


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

Re: [WSG] Safari 3.1 and webkit-border-radius

[Keryx Web]

Rahul Gonsalves skrev:

On a test file [1], Safari 3.1 styles  with rounded borders 
very happily. Perhaps there's something else at play here?


I think I've reduced the problem. There are no rounded corners when the 
fieldset has got a legend element. In my Safari this testcase shows the 
problem.





  Testing why Webkit does not render rounded corners


  Testing why Webkit does not render rounded corners
  
  There really should be rounded corners on this 
fieldset!




  This is another fieldset with no legend. It has rounded 
corners.





I also found the bug: http://bugs.webkit.org/show_bug.cgi?id=12425


Lars Gunther


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

[WSG] Safari 3.1 and webkit-border-radius

[Keryx Web]

Now that safari 3.1 is out I was reminded of something I had intended to 
do for a long time. I took this:


fieldset.inforuta {
padding: 20px;
font-size: 90%;
 -moz-border-radius: 15px;
}

And turned it into this:

fieldset.inforuta {
padding: 20px;
font-size: 90%;
 -moz-border-radius: 15px;
 -webkit-border-radius: 15px;
 border-radius: 15px;
}

I.e. I added support for webkit and any future browser that might 
implement CSS 3 rounded corners.


However Safari 3.1 fails at showing any rounded corners at http://keryx.se/

It should be in the two fieldsets in the right column. Anyone who has a 
clue why? I have tested this on both Safari 3.1 on Win XP and Mac. FFox 
handles the code as both in 2.0.12 and the nightly build from yesterday.


I do send my page as application/xhtm+xml to browsers that claim to 
support that MIME-type (mostly for pedagogic reasons, but that's another 
story). Could this be the cause?



Lars Gunther


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

Re: [WSG] IE 8 and grey

[Keryx Web]

Keryx Web skrev:

Quick question.

I have not got IE 8 beta 1 myself... Does it understand "grey", spelled 
with an e - as it should be ;-)


I have researched this myself now and will set all confusion to rest!

"Grey" is a valid CSS color name defined in CSS 3, not CSS 2.1.

As has been stated previously its equivalent RGB-value is strictly 
defined by the W3C, and color keywords are not deprecated. For pedagogic 
reasons I use them a lot, and also when wireframing.


MSIE <= 7 does only recognize "gray". MSIE 8 beta recognizes "grey" used 
as a value for CSS color, border, outline and background. It also 
recognizes the value set - as you should not! - with the bgcolor 
attribute. It does all of this regardless of its in quirks mode, IE 7 
sub-standards mode or "we are trying for the real deal" standards mode! 
(So much for UA-compatible meta switches!)


At least one webmaster will be surprised: http://www.bebt.com/ Today in 
IE it's a *green* box - which is an exceptionally buggy implementation!


All this I know thanks to "Philip" on the WHATWG IRC channel:
http://krijnhoetmer.nl/irc-logs/whatwg/20080317 (look at the discussion 
around 23:00)



Lars Gunther


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

[WSG] IE 8 and grey

[Keryx Web]

Quick question.

I have not got IE 8 beta 1 myself... Does it understand "grey", spelled 
with an e - as it should be ;-)



Lars Gunther


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

Re: [WSG] Firefox developer toolbar

[Keryx Web]

krugonN skrev:

If I remember right in the FAQ he says that he only makes the toolbar 
once the final version is released. So until FF3 final is released his 
toolbar won't be available :(


More detailed: http://chrispederick.com/forums/viewtopic.php?pid=6796#p6796

Summary: He is working on FFox 3 support. (I can't wait. As soon as I 
have Web Developer and Firebug I'll switch for good. Fangs would be good 
too, but I do not use it daily.)



Lars Gunther


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

Re: [WSG] IE8 news

[Keryx Web]

aleagi skrev:

Hello Mike,

I agree with you.

There's a lot of users still working in obsolete machines or/by
option, browsing with IE6.

That would be all of my colleagues - and me if I want to access the 
intranet for our town. It won't work in MSIE 7 (and hence not in MSIE 8 
with any switch.) I carry around FFox on a USB stick to avoid this 
nightmare.


Yes, I've complained. I have written about it in our local paper. I have 
pleaded. I have done everything in my power. What do the brainiacs at 
the IT department answer. "We don't see this as a problem. IE 6 works."


As long as all sites work in IE6/7 and some intranets won't work in any 
other, we are stuck. Let's do break the web - free from bad browsers!



Lars Gunther


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

Re: [OBORONA-SPAM] RE: [WSG] Best Practice to Offer Different Formats of Documents

[Keryx Web]

Alexey Novikov skrev:

I use this pattern:
Title_of_This_Lengthy_Document, PDF, 1234kb



I would suggest putting the abbreviation PDF and the size inside the 
a-element if anyone tabs from link to link with JAWS or anything similar.



or with icon:
Title_of_This_Lengthy_Document, PDF, 1234kb


I probably would have this image in CSS, aligned right or left and then 
add some padding right/left as well for it to show up. Now that IE7 
supports attribute selectors most users will see it.


If not I would go for an empty alt-attribute, since the purpose of the 
link is clear from the text.



Lars Gunther


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

Re: [WSG] Conflict between Mime Type and Document Type

[Keryx Web]

Rimantas Liubertas skrev:


Can  you elaborate what appendix C are  you talking about?
http://www.w3.org/TR/xhtml-media-types/xhtml-media-types.html#summary
(latest version, supposedly) does not confirm this.



The 2nd edition opens things up a bit:
http://www.w3.org/TR/xhtml11/xhtml11-diff.html#strict


Lars Gunther


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

Re: [WSG] Conflict between Mime Type and Document Type

[Keryx Web]

Thomas Thomassen skrev:
There's no difference between XHTML 1.1 and XHTML 1.0 Strict. XHTML 1.1 
only advantage is that it's modulized 


Not entirely true. XHTML 1.1 includes ruby.

and can only be sent as XML so it 
can be extended. If you're not extending it then you're better off with 
XHTML 1.0.


FWIW - and I do not wish to reopen the "considered harmful" debate - 
appendix C allows for sending XHTML 1.1 as well as XHTML 1.0 as 
text/html. (That's a recent change in the specs that few seem to know 
about.)



Lars Gunther


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

Re: [WSG] This IE8 controversy

[Keryx Web]

[EMAIL PROTECTED] skrev:

One question that I have yet to see anyone ask is: How good will IE8
actually be?
If it is perfect, then there is no need to worry about future
versions...


No browser is, and never will be perfect. (Look at Acid 3. 
http://acid3.acidtests.org/ And when most browsers get that one, we will 
get Acid 4. Ian even has registered a domain name!)


I do not think this applies to you, but I've seen lots of comments 
lately on blogs and forums  complaining about IE - that claims "CSS 3" 
compliance in FFox, Opera or Safari. And that demands perfect CSS 3 
compliance in IE 8. That is some kind of ignorance about the current 
state of CSS support as well as CSS 3 in itself.


Here is the bottom line. If a browser claims to support a (part of a) 
standard, it must do so with 99,9 % perfection. Mozilla is taking a very 
wise route in being rather slow to move from experimental support 
(-moz-box-sizing, -moz-opacity and -moz-border-radius) to full support.


IE7 fixed bugs, but also added features (selector support). I think more 
harm (=sites breaking) was done by the added features, than by the bugfixes.


As for IE I said it before and I'll say it again. NDAs and secrecy is a 
fertile ground for mistrust. Open bug databases is the best way to keep 
developers happy.



Lars Gunther

P.S. In case anyone has missed it. This we can demand from a browser today:
- Full CSS 2.1 support (except for those minute edge-cases where the 
errata still have not been finalized).

- Full support for CSS 3 selectors
- Full support for CSS 3 color (except for one small part of the spec)
- Full support for CSS namespaces

+ Experimental support for background and borders
+ Experimental support for media-queries
+ Paged media and print

http://www.w3.org/TR/2007/WD-css-beijing-20071019/

Unresolved issues/needed errata for CSS 2.1: 
http://csswg.inkedblade.net/spec/css2.1



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

Re: [WSG] This IE8 controversy

[Keryx Web]

Thomas Thomassen skrev:

Yes, that is an issue. But saving webpages to disc has always been 
unreliable. Espesially now with the extensive use of AJAX and other 
embedded and streamed content.


Not to mention IE:s habit of botching up the markup badly. Valid and 
well-formed XHTML will often be saved with tagnames and attributes in 
UPPER CASE!


That an UA might automatically insert a meta-tag for IE-dummy-mode is 
not that hard to imagine, though.


The problem is that it would have to *required* behaviour for *every* 
UA! And that includes "Lynx -dump", wget, and every other program that 
people use for scripted solutions.



Lars Gunther
Who uses wget a lot...


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

Re: [WSG] Revolutionary news

[Keryx Web]

russ - maxdesign skrev:


It is a very interesting chart (I haven't seen anyone map out the IE8
situation this well), but it also renders poorly in Safari (can't read a lot
of the text)... Do you have a simpler version of the chart (like, horror of
horrors, an image) you could post and then link here for discussion?


*Images*

Here is the PNG that's used as a fallback to my SVG-chart:
http://keryx.se/dev/svg/geckobug-08-01/ie8-metatag.png

I have also added a link on the HTML-page.

If anyone wishes to edit the original in Dia, here's that link:
http://keryx.se/dev/svg/geckobug-08-01/ie8-metatag.dia

*SVG*

Concerning the SVG situation:

Here is the PDF with screenshots in many different browsers:
http://keryx.se/dev/svg/geckobug-08-01/SVG-bug-in-firefox.pdf

I received feedback today on the SVG bugs, saying the SVG looks perfect 
in Opera 9.5 beta and, FWIW, Firefox 1.5 on Ubuntu.


Here is the bug that makes FFox 2.0 go bananas with minimum font size: 
https://bugzilla.mozilla.org/show_bug.cgi?id=290044


If anyone knows what bug it can be that makes FFox 3 handle my SVG worse 
than FFox 2, please help me find it or report it. Safari 3 and FFox 3 
might share a substantial amount of code, since they get it equally wrong...



Lars Gunther

P.S. You may treat all this as "public domain" if you wish to edit and 
reproduce it.



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

Re: [WSG] Revolutionary news

[Keryx Web]

Patrick H. Lauke skrev:
doubt it. XHTML 1.0 can be served as text/html, and that's probably what 
he's referring to.


May I also add that I do not trust this enough to add it to my flowchart 
that I've done to illustrate MS proposal... (Which hits a nasty bug  in 
FFox!)


http://www.molly.com/2008/01/24/me-ie8-and-microsoft-versioning/#comment-975363


Lars Gunther


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

Re: [WSG] Revolutionary news

[Keryx Web]

Patrick H. Lauke skrev:

Keryx Web wrote:
He is telling us that we (soon?) can use application/xhtml+xml and 
that MSIE will support it. Am I hearing this right?


doubt it. XHTML 1.0 can be served as text/html, and that's probably what 
he's referring to.


Yes, I doubt it too, but he *is* talking about *MIME*. If this is a slip 
of the tongue, it is remarkable.



Lars Gunther

BTW, I've read your comments on about a thousand blogs. Thank you for 
doing the right thing!



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

[WSG] Revolutionary news

[Keryx Web]

Could this be true? MSIE 8 will support true XHTML...

Chris Wilson wrote this on Jeremy Keiths blog:

"Jeremy - any content-type or DTD that is not broadly deployed when we 
ship can be opted in to best standards support. So HTML5 can be opted 
in; the XHTML mime type could be, as could any other MIME type IE7 
doesn’t recognize."


http://adactio.com/journal/1402/#comment246

He is telling us that we (soon?) can use application/xhtml+xml and that 
MSIE will support it. Am I hearing this right?



Lars Gunther


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

Re: [WSG] how to set table column widths with CSS

[Keryx Web]

Philippe Wittenbergh skrev:


I'm styling the  element, not a descendant or child of col (there 
are none, anyway).

(col:first-child applies to the first column, child of colgroup)

width applies perfectly to the  element.



I was surprised to see that until this post no one had referred to using 
width on col, as it is one of the four allowed properties.


Maybe this subject is tricky as MSIE support too many properties!

I keep coming back to this in discussions everywhere:
http://ln.hixie.ch/?count=1&start=1070385285


Lars Gunther


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

Re: [WSG] Acronym element

[Keryx Web]

Ross Bruniges skrev:

the abbr and acronym elements have extra value
in the fact that a screen reader will say
out each letter opposed to trying to pronounce the word.


Here is how I understand the difference between an acronym and other 
abbreviations:


Acronyms should *not* be spelled as, but spoken like a word, as in 
"NATO", "AIDS" or "Benelux".


Initialisms are very similar, except that the individual letters should 
be pronounced separately, as in FBI or HTML.


Some abbreviations should be replaced with other words completely when 
spoken. Like "e.g." = "for example" or "i.e." = "that is", or perhaps 
"ROTFL".


Ergo: Screen readers should not spell out the contents of an *acronym* 
element, but should spell out the content of *some* abbreviations.


In an ideal world, screen readers should be programmed to recognize 
common abbreviations and speak naturally when they encounter one.


In an ideal world screen readers should know when to apply media types 
(screen, tv, projection, speech, braille, etc) and media groups 
(contunuos/paged, visual/audio/speech/tactile, interactive/static)


In the real world they do not and we have to compromise. This is a 
beautiful(?) vision only:


@media audio {
abbr, acronym {
speak: normal;
}
abbr.replace {
content: attr(title);
}
abbr.initialism {
speak: spell-out;
}
}

"Aural", BTW, is 
CSS 2.0, not 2.1.



Lars Gunther



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

[WSG] Ordinal numbers with roman numerals

[Keryx Web]

Hi again!

I do have a lot of questions - at least a few at the moment.

How do you handle ordinal numbers in order to satisfy both the normal 
reader as well as screen readers.


a. Today, when a screen reader *might* read both an elements textcontent 
and it's title-attribute, it's title attribute instead of the content or 
only the content.


b. In a perfect world where screen readers are @media aware and all 
browsers support CSS 2.1 fully.


Example:

"The Swedish king, Carl XVI Gustaf..."

The goal is to have people seeing "XVI", but not the unnecessary tooltip 
the title attribute would produce, have printers and braille terminals 
spell XII, but have synthetic speech say "the sixteenth".


In my *perfect* world I would detect the media type and turn the tooltip 
off with JavaScript, and use the following CSS for speech:


@media speech {
/* Find all elements that has a title attribute that
   ends with "eenth" */
*[title$=eenth] {
content: attr(title);
/* replaces the content with the attribute value */
}
}

(Unicode used below.)

However, I know of no way to detect the media either in JavaScript 
today, nor in any proposed standard for the future. Getting rid of the 
tooltip is of lesser importance, IMHO, than suppressing /ɛks viː aɪ/ 
from being spoken.


A totally different approach would be to use the designated Unicode 
sequence for Roman numerals[1] and have screen readers know that they 
should spell that out as numbers. How the would see the difference 
between "sixteen" or "the sixteenth" I do not know, though.


This approach also requires authoring tools to force all writers to 
actually use the proper Unicode characters, which might be hard. Auto 
correction in the background that pops up a question every time it 
detects something that might look like a Roman numeral may be very annoying.


In Sweden we say "vi" when we mean "we", so 99.9% of all times that 
character sequence is being typed it should not be changed. 
Occasionally, though, we might speak about our former king, Gustav VI 
Adolf...


Lars Gunther


1. http://en.wikipedia.org/wiki/Roman_numerals#Unicode






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

Re: [WSG] When can I start using E4X

[Keryx Web]

Keryx Web skrev:

He all!


Should have been Hi all!

Answering (partially) my own question.


Webkit:
"The E4X standard adds some XML-related features to the
 JavaScript language. We should consider adding these to the
JavaScriptCore engine."



I found the tracking bug as well: 
http://bugs.webkit.org/show_bug.cgi?id=5381


No movement registered whatsoever!

I see no tracking bug at http://bugs.kde.org/



Lars Gunther


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

[WSG] When can I start using E4X

[Keryx Web]

He all!

I have been searching the net for rumors and facts about E4X 
implementations. This is what I've found:


Mozilla (Spidermonkey and Rhino) support E4X today - and has been doing 
it for a while!


Adobe does too.

So does (already/soon?) MbedThis. At least they are 100% committed.

Webkit:
"The E4X standard adds some XML-related features to the
JavaScript language. We should consider adding these to the
JavaScriptCore engine."

http://webkit.org/projects/javascript/index.html

My interpretation: Positive attitude, but no commitment.

Opera:

I can not find an official quote, but rumours on the web says they are 
committed, as in "Only Mozilla and Opera have committed just to E4x"

http://theopensourcery.com/cssbasics6b.htm
"I know Opera have E4X in the works at some level"
http://www.codingforums.com/showpost.php?s=a9dfc400dfd427203a99487bd4ea29d9&p=448007&postcount=10

KHTML:

No info available, AFAIK. If it goes into webkit, I presume a backport 
would be feasible. (Or perhaps the rumors about merging with Webkit are 
true...)


iCab seems to be on board as well:
http://www.snailshell.de/blog/archives/10-01-2005_10-31-2005.html

Which in summary says that only MS are clearly unwilling to implement 
this feature. We may get it through ScreamingMonkey, though.


My questions:

1. Are there any clear indications from the developers of these browser 
engines (or their internal ECMAScript engines) that I've missed?


2. Will E4X on MSIE in fact be facilitated through ScreamingMonkey?

3. When do you predict that we can really start using E4X and expect it 
to work for most visitors to our websites?



Lars Gunther



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

Re: [WSG] Numbers in HTML 5 Was: Appropriate use of the ABBR tag and Roman Numerals

[Keryx Web]

David Dorward skrev:

On 2 Dec 2007, at 13:08, Keryx Web wrote:

Consider the following, more common problem:
I want to write a big number, say 2345678912.123
How big was it? Hard to see, isn't it? Let's add thousand separators 
the American way:

2,345,678,912.123
Yea, now I see how big it really is.
But in Sweden we would write it like this:
2 345 678 912,123
Bu neither way is good for anyone using a screen reader. I would like 
the screen reader to actually say:

2 billion 345 million 678 thousand 912 point 123
Not:
2 comma 345 comma 678 comma 912 point 123


Is the information needed to do that not available from the lang attribute?




If I separate numbers, how will the screen reader know my intention?

This is a phone number:

123 432

This is an ordinary number:

123 432

What in the lang-attribute says the first shall be spoken differently 
than the second? At least in Sweden we would.



Lars Gunther


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

Re: [WSG] Numbers in HTML 5 Was: Appropriate use of the ABBR tag and Roman Numerals

[Keryx Web]

Kepler Gelotte skrev:

That's interesting. I had thought of the lang attribute as well but didn't
think that Roman Numerals were attached to any language in particular (as
Lars points out). 


I think maybe the HTML specification needs something like a num attribute
that allows you to specify the numeric system (e.g. 10011). Maybe this is too much classification being
added to HTML though. 



Ages ago I suggested on the WHAT-WG list that HTML 5 should have a 
number element or a number attribute. Did not meet with any enthusiasm, 
though.


I will try to resuscitate it. Maybe some input from the members of this 
list will be of value.


 Problem -

Consider the following, more common problem:

I want to write a big number, say 2345678912.123

How big was it? Hard to see, isn't it? Let's add thousand separators the 
American way:


2,345,678,912.123

Yea, now I see how big it really is.

But in Sweden we would write it like this:

2 345 678 912,123

Bu neither way is good for anyone using a screen reader. I would like 
the screen reader to actually say:


2 billion 345 million 678 thousand 912 point 123

Not:

2 comma 345 comma 678 comma 912 point 123

Or:

2
345
678
912
comma
123

And I definitely would not like the number to be split across two lines 
if it's at the end of one or in a table cell. This could be remedied by 
using non breaking space as a thousand separator, but that's a solution 
that no CMS uses as far as I know, and it does not solve the problem 
with screen readers.


Numbers may also be part of something that should be machine parsable, 
perhaps with JavaScript. For such a scenario it is better to not have 
any thousand separators as well.


There is a CSS rule that deals with the formatting of numbers: 
-mso-number-format. However, it is only used when Excel imports data 
from HTML, to set the formatting in Excel.


 Proposed solution 

I would suggest the following:

2,345,678,912.123

Together with a W3C approved CSS-rule: number-format, based on 
-mso-number-format.


This degrades gracefully as todays browsers would just show the number 
as I've formatted it manually.


Suggested formats:

1. baseN, where N normally would be 10, 2, 16 or 8, but could be any 
number. Perhaps with aliases: dec, binary, hex, octal.


2. Latin

3. Fraction

4. Greek, hebrew, etc may be added as well

The actual value will be parsed by the browser and be made available to 
JavaScript through a DOM-property: E.title.


This property might be added manually as well, as in:

title="2345678912.123">2,345,678,912.123


Using title in this way will make the actual value available to screen 
readers. (Graceful degradation once again.)


Parsing rules:

1. If there is a manually set numeric value, it shall be used.

2. If not, parse according to the format. Suggested algorithm for 
decimal numbers follow:


a. Strip out everything thats not a number, except any decimal separator 
and percentage sign.


b. If there is a percentage sign, divide by 100 and strip it out as well.

3. If any CSS-rule has been set, redraw the number using that. Default 
rules in the browser shall follow the language. An author may override 
these using the language selectors in CSS.


This allows for easy localization. I can use space as a thousand 
separator - line breaks within a number element would by default be 
prohibited by the browser - but any American visiting my site could 
still see commas.


If it would meet with approval, this also can be expanded with:

A. Numbers as input-rules for form fields. 

B. Attribute for table cells. I.e.  is short for 




Lars Gunther


My original suggestion to WHAT-WG:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006530.html


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

Re: [WSG] Appropriate use of the ABBR tag and Roman Numerals

[Keryx Web]

Geoff Pack skrev:
 
Since they're Roman numerals, shouldn't there be a lang="la" in there

somewhere?
 
Roman numerals may be used in more languages than latin. They are simply 
put just another way to write a number.


Lars Gunther

Who BTW has read Latin...


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

Re: [WSG] Leopard mail and standards

[Keryx Web]

To everybody who has answered me in this thread:

1. I do realize that it is impossible to use perfect markup today, 
mainly because of the ghastly Outlook 2007. (A product I am boycotting 
BTW - but tell the to the mobile phone manufacturers. "It syncs with 
Outlook" is the ubiquitous sales pitch.)


2. I do realize that the rendering engine in use will be the same one as 
in Safari, which means really good CSS support but rather crappy (but 
improving) JS/DOM support (which is a non issue in mail, IMHO).


BUT: When I outlined the issues (accessibility, separation of concerns, 
valid code) my question was perhaps a bit too unspecific. Will they 
implement best practices as far as it is possible today. Will it be step 
in the right direction or yet another step away from it.


In my world its a sliding scale, not an either - or!


Lars Gunther


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

[WSG] Leopard mail and standards

[Keryx Web]

When Outlook 2007 came out it incurred upon itself the righteous wrath 
of all standardistas thanks to the stupid decision to use Word as its 
HTML/CSS rendering engine.


In a few days Mac OS X Leopard will be out with much touted templates 
for the mail app. Here is my question: Are these made with standards, 
accessibility and separation of concerns in mind?



Lars Gunther


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

Re: [WSG] Catch 22 list problem

[Keryx Web]

Jens Brueckmann skrev:


there do exist counters in CSS, see

  http://www.w3.org/TR/CSS2/generate.html#counters

but, as you might have guessed, they are not supported by Internet Explorer.


Yes. I was a bit too short on that one...


As you already observed, list counters are rather content than
presentation, so either CSS or JavaScript are somewhat questionable
for achieving your aim.

So personally, I would either ignore the validation problem or use a
customized DTD.



Next question: How would a custom DTD affect standards-compliance vz. 
quirks mode. That is a subject that I have no knowledge about.


I totally agree that a custom DTD is *the* best solution, though - 
provided it will not trigger quirks mode!



I prepared a short example at http://lairx.de/071011/numbering-lists.html


Triggers strict mode in Firefox - what about MSIE, Opera, Safari, etc?


It uses an extended DTD, where the VALUE attribute for the LI element
and the START attribute for the OL element have been added.
Furthermore a CSS example using automatic numbering is provided.



Great stuff. Thanks!

Also: Thanks to everyone else that has replied to my question!

Doing some small experiments I think there might be an additional reason 
why one should be cautious in setting list-numbers in CSS. It makes it 
harder to access and/or change those numbers in JavaScript.



Lars Gunther


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

[WSG] Catch 22 list problem

[Keryx Web]

Hi all!

Short version:

A.  is not allowed in strict HTML 4/XHTML 1.0, Spec says 
"use CSS".


B. I want to start at 3.

C: CSS has no means to specify a start value!

Pick your poison:

1. Invalid code
2. Use a transitional DOCTYPE
3. Set value with DOM-script


Long version:

How do we handle clear errors in the (X)HTML specs? This one seems to 
indicate:


a. Lack of communication between (X)HTML WG and CSS WG at W3C
b. Bad thinking by the (X)HTML WG (in the past - on this issue), as the 
starting value is content, not presentation.


But regardless of whom I should blame there is a problem to solve. I 
would like to know which solution that you would use and why.



Lars Gunther


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

Re: [WSG] (X)HTML Best Practice Sheet - CSS issues

[Keryx Web]

Anders Nawroth skrev:


You are looking for thead/tbody HTML elements:


No, I want to stop the leftmost *column* from scrolling as well!


Lars Gunther


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

[WSG] CSS, the DOM and whitespace (rant)

[Keryx Web]

Hi again!

CSS considers only element nodes to be children or siblings. The DOM 
does not.


This is a pedagogic discrepancy understandable to people used in 
traversing the DOM who are frustrated that MSIE is "natural" with 
nextSibling and that the rest are according to spec.[1] Something that 
has led to the Element Traversal Specification[2] and a lot of userland 
convenience functions[3].


As for the DOM the spec actually makes sense, even if whitespace-only 
text nodes can be ignored 99% of the time. Compare the following:



  bar


with:


  I really mean it.


In the first case the whitespace nodes are clearly without any real 
value. In the second case that is true for the first whitespace only 
text-node, between  and , bit the second whitespace only text 
node is useful, because it separates the word "I" from the word "really".


In CSS 3 there will be new selectors, and I wonder if it would not be 
useful to clearly specify when whitespace is indeed ignorable and when 
it is of real use. Consider the following:


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>
  
Test CSS 3 only-child selector

  li > a {
background: lightblue;
  }
  li > a:only-child {
  background: pink;
  }

  
  
Test CSS 3 only-child selector

  True only child XML-wise
  
Not only child XML-wise (whitespace)
  
  Dummy text
Clearly not only child XML-wise (textnode as 
sibling)

  
  Dummy text in span
Clearly not only child XML-wise
  

  


When I run this in FFox 2.0 I get three pink background a-elements and 
the forth is light blue. One could reasonably argue that it should be 
the other way around. But it is according to the spec[4]:
The only-child pseudoclass "Represents an element that has a parent 
element and whose parent element has no other *element* children. Same 
as :first-child:last-child or :nth-child(1):nth-last-child(1), but with 
a lower specificity." (emphasis added)


Ergo: The second and third a-elements are not an only child from the DOM 
point of view, but they are from an CSS POV.


Now to the question... Ooops! I actually forgot what I had intended to 
ask. Well, enjoy my little CSS 3 test if nothing else...



Lars Gunther


1. 
http://easy-designs.stikipad.com/IE-next-Wishlist/show/Don%27t+ignore+whitespace


2. 
http://dev.w3.org/cvsweb/2006/webapi/ElementTraversal/publish/ElementTraversal.html?rev=1.4


3. Example from w3schools (there are better ones):
//check if the next sibling node is an element node
function get_nextsibling(n)
{
  var x=n.nextSibling;
  while (x.nodeType!=1)
   {
   x=x.nextSibling;
   }
  return x;
}

4. http://www.w3.org/TR/css3-selectors/#only-child-pseudo


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

[WSG] (X)HTML Best Practice Sheet - CSS issues

[Keryx Web]

Philippe Wittenbergh wrote:
> Mind if you add some different background colour on alternate rows
> or some such ?
> The table is much wider than my monitor (or my browser window,
> which is probably more important...), and it is quite difficult
> to keep track of things.

Alternate row colors will come with an XSLT solution as todays browsers 
do not honor tr:nth-child(odd/even), except for Conqueror I believe.


The Open Office version has a nice feature. The headings are fixed when 
you scroll. One can't duplicate that in a table with CSS as far as I 
know ("position: fixed" for table columns and rows...)



Lars Gunther


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

Re: [WSG] (X)HTML Best Practice Sheet updated for MSIE

[Keryx Web]

I have now made it possible for MSIE to see my sheet as well.

I have provided an plain HTML version, but do not want any linking to 
it. This is the set of rules in my .htaccess that I think should do the 
trick:


---

RewriteEngine On

# The simple html version shall not be directly accessible!
RedirectMatch 301 html-elements-plain\.html \
http://egen.keryx.pad/resources/html-elements.xhtml

# The next ruleset changes nothing but should stop the following \
from executing
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
RewriteCond %{REQUEST_URI} \.xhtml
RewriteCond %{THE_REQUEST} HTTP/1\.1
RewriteRule .* - [L]

# Go easy on MSIE and some bots
RewriteCond %{REQUEST_URI} \.xhtml$
RewriteRule html-elements.xhtml html-elements-plain.html "[T=text/html]" [L]

---
It works with FFox, Opera 9.2, Safari for Windows (complained at first 
about too many redirects for no apparent reason) and MSIE 6. The latter 
will miss two CSS 3 selectors and inserts line breaks like this:


[B]
lock(-
ish)/
[I]
nline(-
ish)/
[T]able

Any easy way to fix this except for ?



Please report any problems ASAP as I see that some people have started 
to link to my little sheet. (At least three on Magnolia...)



Lars Gunther

P.S. MSIE will not recognize the check mark on my XP box, neither will 
Safari.



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

Re: [WSG] (X)HTML Best Practice Sheet goes live - correct link

[Keryx Web]

[EMAIL PROTECTED] skrev:

I'm afraid this doesn't give me much confidence when your label for
HTML5  is (X)HTML 5
One of the major points about HTML5 is that it is _not_ XML based.


Already answered by liorean. May I add that prominent members of the 
WHAT-WG mailing list have read and OK'd my document as well.


Second point would be what do you mean by Block(ish)? 


"Block(-ish)/Inline(-ish)/Table refers to default CSS rendering."

Blockish: Real block elements, list-item

Table-ish:  table, table-row-group, table-header-group, 
table-footer-group, table-row, table-column-group, table-column, 
table-cell, table-caption


No element defaults to: run-in, inline-block, inline-table, marker or 
compact.




Lars Gunther


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

Re: [WSG] (X)HTML Best Practice Sheet goes live - correct link

[Keryx Web]

David Dorward skrev:

On 10 Aug 2007, at 08:53, Dean Edridge wrote:

But it's not supposed to work in ie5, 6 or 7. It's a XHTML document.


But why? I can't see anything that could not be expressed in HTML in 
that document.




XSLT and perhaps SVG is coming...


Lars Gunther


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

Re: [WSG] (X)HTML Best Practice Sheet goes live - correct link

[Keryx Web]

Frank Palinkas skrev:


May I make one suggestion please? The character reference (✓) you're
using for the "checkmark" symbol does not render in IE6 or below. However, it
does render perfectly in the latest versions of Opera, Firefox, Netscape and
Safari for Windows. 


It does *not* render perfectly in my version of Safari for Windows (the 
latest beta), so this is probably a font issue.


Since the page is sent as XHTML and uses CSS3-selectors, MSIE is 
basically out of the question anyway.


My plans for the future is to improve how the checkmark, the "D" for 
deprecated, "I" for inline, "R" for replaced, etc are presented by som 
XSLT/JavaScript enhancements.



Lars Gunther


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

Re: [WSG] (X)HTML Best Practice Sheet goes live - correct link

[Keryx Web]

Andrew Freedman skrev:

Any chance that you could perhaps upload the page or post the correct link?



Ooops!

http://keryx.se/resources/html-elements.xhtml

Sorry all!


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

[WSG] (X)HTML Best Practice Sheet goes live

[Keryx Web]

Hello everyone on the mailing lists that I have used to produce my 
(X)HTML Best Practice Sheet!


It is no longer called a "cheat" sheet, and it has gone live today. 
Check it out at http://keryx.se/resources/html_elements.xhtml and feel 
free to use it or as you please - or improve it!


There are three versions: XHTML, PDF and Open Office. Use whichever you 
prefer. Content-type: application/xhtml+xml and CSS3 selectors are used. 
It may look bad in some browsers and MSIE will choke!


As for accessibility: There are a lot of headers. It might not be easy 
to listen with a screen reader, and I have yet to solve the question 
about sub-section headers in my table.



Lars Gunther


P.S.

It has been tested with Firefox 2 and Opera 9.22

The latter has a peculiar bug: The topleft corner in the table shall 
have no border top or left. Scroll down and the back up and a border 
will hang in the air...)


Safari for Windows does not support the check mark ✓ but renders 
most things OK.


Reason for XHTML: I intend to use some XSLT on this doc further ahead...


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

[WSG] Usefulness of JSDoc

[Keryx Web]

Hi all!

I have been wondering about the (absent) standard for documenting 
JavaScript: JSDoc.


In PHP one can expect any seasoned developer to use PHPDocumentor (or 
something similar, like Doxygen). In JAVA one would expect Javadoc to be 
used by most.


However, except for Foundations of Ajax (ISBN 1-59059-582-3) I see *no* 
other book on the market using or promoting the use of JSDoc. And as far 
as I know YUI is the only major library to use it.


"Gurus" like David Flanagan, John Resig, Christian Heilmann, Dean 
Edwards and PPK are all silent on this matter, and do not use JSDoc in 
any code I've seen them write. Admittedly they write a lot, but JSDoc 
are absent from their books and blogposts, at least.


1. Is JSDoc not a good idea? If so, why not?

2. If it is, why has it not caught on?

Coming to JS from a back-end developer perspective I find this very strange.


Lars Gunther

P.S.
References:
http://jsdoc.sourceforge.net/
http://en.wikipedia.org/wiki/JSDoc


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

[WSG] JavaScript gurus - exercise in vanity

[Keryx Web]

Hello all!

Who, in your opinion, are the 5 best JavaScript gurus?

This is a question that might seem silly, but there is actually a great 
deal of thought behind it. I am working on a paper at university level, 
that intends to describe the benefits of unobtrusive DOM-scripting, 
compared to old school inaccessible DHTML or badly written AJAX apps. I 
intend use arguments such as "the leading experts say..." and "the most 
esteemed writers - such as N.N. and N.N. - argue that..."


A guru would be someone that has consistently lead the way through 
developing ground-breaking patterns and/or top notch apps and who has 
written about it in books and/or on the web. Someone who is regarded as 
a master by his (or her) peers. Some geniuses may be working in 
obscurity - so this is not a a competition as to who is the "best" 
developer.


And yes, I realize that all answers will be subjective and IMHO...

I will kick off this discussion with my list:

1. Brendan Eich - he invented the language and leads it's continual 
development into JS 2. Hard to ignore.


2. Douglas Crockford. JSLint, JSMin, JSON; inheritance, 
public/private/privileged methods... and a superb lecturer.


3. David Flanagan. Only author recommended by DC! At least until 
recently. But the Rhino book is still the seminal work on JS - right?


4. Dean Edwards. Inventor of numerous genial projects (Base, CSSQuery, 
Packer...) Nice blog that is always a learning experience to read. He 
tends to be read by many pros.


5. PPK. He has been running quirksmode fore quite some time now. Main 
author of WASP's JavaScript Manifesto. Author of the best JS book from a 
 pedagogic POV.


Apologies to anyone not on my list...


@listdad: If this is off-topic, please say so.

@rest: If this discussion is considered OT, you may answer me in private.


Lars Gunther


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

Re: [WSG] Accessible Drop Down

[Keryx Web]

Ryan Moore wrote:



I see that it relies on a source of JS to complete the effect, and i'm 
wondering if it's possible to complete this purely with XHTML & CSS.  
Anyone have a good example of this?


Just do not do it. It cannot be done.

a. JS is the best tool for *behavior*. CSS for design.
b. There are huge accessibility and usability issues with pure CSS 
menus, such as:

- off-screen positioning
- moving the mouse the shortest distance will often lead to the menu 
getting closed

- non-intuitive keyboard navigation

Etc

Lars Gunther


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

Re: [WSG] WCAG Samurai Errata

[Keryx Web]

Tee G.Peng wrote:


Hi, I finally got a chance to read the WCAG Samurai Errata. Maybe 
something to do with my understanding in English, I see there is 
autority tone in there.


Guideline 11, bullet point 3, point 4: "I really mean this..."


Not so convincing, perhaps?


Lars Gunther


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

[WSG] Wikipedia article help wanted

[Keryx Web]

Hello everyone.

A few months ago I started this article on Wikipedia:
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28ECMAScript%29

However, my wife has got ill and received a heart transplant, so my time 
and energy for Wikipedia articles are somewhat lacking. If some of you 
could find it in their hearts to help bring the article to maturity it 
would be great. I hate to leave it unfinished.



Lars Gunther

P.S. The operation went fine and she is now back home with me, but it 
will be a while until all strength is regained.



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

[WSG] Alpha transparency problem

[Keryx Web]

Hi all!

Is it possible to get MSIE 6 to have a repeated alpha-transparent png
background? Check this page http://ne.keryx.se/~gorgnut/new_site/

It is made by a student of mine and the faded border is supposed to
stretch and the hacks for MSIE I know can't be used if the image gets
repeated.


Lars Gunther




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

Re: [WSG] Standards War - HTML 5 vs XHTML 2.0

[Keryx Web]

Adrian Lynch wrote:


Knowing that  XHTML5 is developed in the same spec means that we can
push forward with our XSLT based workflows, and simply adjust to suit
once XHTML5 is supported at the browser level.

--


I had the same concern. As it turns out one can - at least in many cases
- use the XML tools with the HTML-serialization as well. My
understanding was corrected through the interchange in the following thread:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009473.html

Lars Gunther




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

[WSG] XHTML vz HTML speed

[Keryx Web]

Hello again!

Firefox 3.0 will support incremental rendering of true XHTML, since bug 
18333 has been fixed: http://bugzilla.mozilla.org/show_bug.cgi?id=18333 
and http://www.mozilla.org/projects/firefox/3.0a2/releasenotes/


One argument in support of XHTML has been "speed" (seldom heard today, 
though) and one argument against it has been "speed" - no incremental 
loading. However, Gecko seems to be the last XHTML-aware browser to 
implement this, so in a short while the speed argument should work only 
in support of XHTML.


My question:

I wonder if anyone has *measured* any speed differences between 
application/xhtml+xml and text/html in Opera, Safari or Firefox/Gran 
Paradiso alpha 2? Are there any results posted somewhere?



Lars Gunther



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

[WSG] (X)HTML best practice cheat sheet

[Keryx Web]

This message has already been posted to the what-wg mailing list and to 
the wasp-edutf mailing list. Please forgive duplication and feel free to 
ignore...


Hello yet again!

For the benefit of myself and my students I have started to put together
a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML
1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use
today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some
XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as
reference, to provide a historical perspective and some preparation for
the future.

Unlike other cheat sheets the emphasis is not on syntax, but on proper
usage. Any feedback on my work is greatly appreciated.

The cheat sheet is available (during development) at:
http://keryx.se/wasp/html_elements_beta.pdf
http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc)

It is primarily intended for print, but when it reaches 1.0 status, I
will probably make an HTML version as well.

A few notes:
- I have grouped the elements according to how I teach. It may not 
reflect the way you think of them, and it does not reflect any spec. 
Known issue - I won't change it.
- All advice is appreciated, but if it can't be boiled down into 
something short I can't use it. Please feel free to suggest a wording.
- If you would like to give me feedback by changing the OO-document and 
mailing it to me, please use the versioning so I can track your 
suggestions and criticism.


Many thanks.

Lars Gunther


P.S. I'll include anyone who provides feedback in the document. It 
currently says:


The recommendations in the table above represents the personal opinion 
of Lars Gunther, although valuable suggestions have been provided by 
April Siegfried, Christian Montoya, Alexey Feldgendler and Simon 
Pieters. This list is intended to be used as a reference while coding 
(or seeing other's code) and as notes for learning (X)HTML. Strict 
doctypes that are supported by the browsers of today is recommended for 
normal web pages. XHTML 1.1 Mobile is recommended for pages primarily 
intended for cell phones and similar devices (WAP 2.0). Proprietary 
elements are included for reference if stumbled upon. A few XHTML 2.0 
and most (X)HTML 5 elements are included as examples of where (X)HTML 
might be heading in the future.





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