Re: [WSG] JavaScript clarification please

2008-10-28 Thread liorean
 liorean wrote:
 (Netscape had originally intended to use the name LiveScript.)

2008/10/28 Hassan Schroeder [EMAIL PROTECTED]:
 Actually, it was initially released as LiveScript and renamed later.

IIRC Navigator 2.0 also supported a mocha: pseudo-protocol like the
javascript: pseudo-protocol we have today, from the name it was given
before it became LiveScript. Anyway, by the time the first full
version of Navigator that had it was released (2.0) it had already
been renamed to JavaScript, so I'd hardly say it was released under
the LiveScript name.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-28 Thread liorean
2008/10/28 Brett Patterson [EMAIL PROTECTED]:
 Actually it did say it is heavily object-based. But now, under Dynamic
 Programming -- Objects as associated arrays, it says it is almost entirely
 object-based. Looks like it just got updated. Internet Explorer does read
 JavaScript, but does it support JavaScript as a whole, or does it read
 JavaScript as JScript?

That depends on what you mean by JavaScript. Do you mean the language
that Netscape JavaScript and later Mozilla JavaScript reference[1] and
guide[2] specs specifies? JavaScript as in the language
text/javascript is interpreted as in browsers? Do you mean the
entire language and host environment making up the client side
scripting language for web pages?

The word JavaScript means different things in different contexts to
different people.


Internet Explorer uses Microsof't JScript engine which implements
ECMAScript, some parts of it buggy, some parts of it with proprietary
extensions. It doesn't in general implement Mozilla JavaScript
additions to ECMAScript. It does send all content that tells it it is
JavaScript/LiveScript/JScript/ECMAScript to the same engine.


[1] https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference
[2] https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-27 Thread liorean
2008/10/27 Brett Patterson [EMAIL PROTECTED]:
 Yes. But, one final question. Was the first ever implementation of
 JavaScript designed to be object-oriented, object-based, or prototype-based?
 Thank you all.

The first implementation of JavaScript is still alive in the form of
Mozilla SpiredMonkey, even though much of it has been changed since
then. It was designed to be object oriented through usage of the
prototypal inheritance scheme, so it's pretty much all three at once.
Since everything in JavaScript is an object, it can be said to be
object based as well as object oriented. Anthony Ziebell's argument
that it's prototype-based rather than object oriented is a false
dichotomy since prototypal inheritance is in fact one of the ways to
achieve objevt orientation. As such, a system can become object
oriented as a result of adding prototypal inheritance to an object
based system.

Anthony Ziebell is arguing that it's not object oriented based on the
false premise that classical inheritance is the way to achieve object
orientation and prototypal inheritance is not, despite himself linking
articles stating the contrary.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-27 Thread liorean
2008/10/27 liorean [EMAIL PROTECTED]:
 The first implementation of JavaScript is still alive in the form of
 Mozilla SpiredMonkey

Or SpiderMonkey, as it is properly called :)
--
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-27 Thread liorean
2008/10/27 Anthony [EMAIL PROTECTED]:
 My arguement was that while javascript has objects, it is indeed
 prototype-based

Oh, we're not disputing that. But look at some of your earlier comments.



This for instance:
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 Sure, that's what an object is. But OOP is not just about an object.
 There is a lot more involved.

 Don't get me wrong, I am a fan of JavaScript - but it has faux classes and
 objects, and this is why my opinion of JavaScript is that it is prototype,
 not object.

First of all I'm assuming you meaning object-based and prototype-based
there, because the sentence as written just does not make sense.
Anyway, it's a false dichotomy because JavaScript is object-based AND
prototype-based. It's also object oriented.

Also, while you can say it's got faux classes (it actually has in the
ECMAScript specification, but nothing author accessible) those classes
have no greater importance to the author as they are not available to
user JavaScript.


Here's another such statement of yours:
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 Forgot to clarify one thing: ECMAScript is fully OO in my opinion, however
 JavaScript is not a full implementation of ECMAScript, unfortunately.

This sounds like you're insinuating that while ECMAScript is fully
object oriented, JavaScript is not. That's just plain false.


Another one:
2008/10/27 Anthony Ziebell [EMAIL PROTECTED]:
 There is a difference between the use of object and object-oriented
 programming. Coad / Yourdon suggests object-oriented being classes and
 objects, inheritance and communication with messages. Does JavaScript have
 classes?

Not user classes, no. Only implementation/host.

Can inheritance of JavaScript occur without prototype?

Not automatically, no. Why would it need another inheritance mechanism
in order to be object oriented?

 [snip]
 Object-oriented programming consists of native inheritance. Are you
 suggesting that a prototypical approach to inheritance one in the same as
 native inheritance?

Do you mean native as in the implementation language (machine
native, if you will) or native as in user JavaScript?

Anyway, the inheritance mechanism in JavaScript is prototype
delegation, and it certainly is the native method of inheritance for
JavaScript. It may or may not be the method of inheritance for host
objects, but that's another story.




2008/10/27 Anthony [EMAIL PROTECTED]:
 It is only through arguement did any mention of javascripts inheritence get
 a mention, which is also still true. This was not the underlying factor, but
 something somone brought up.

It's the core part of being a prototype-based language, so even if
you've not mentioned inheritance you've certainly talked about it. But
you have at several occasions mentioned inheritance, so that's beyond
the point.

 I'm not sure why it is so bad that javascript be prototype-based? I have
 said again and again that it still does have objects, sighted many sources
 which state javascript as a prototype-based language and other examples for
 the arguement along the way... It is still a good language and there is
 nothing negative about prototype?

We're not arguing about that. We're arguing that it being
prototype-based is the very factor that makes it object oriented. But
you on the other hand have at least seemingly argued that it is not
object oriented, which is the point we've been addressing all along.

 Anyway I only respond again because I don't like to be miss-represented. If
 you still feel I am wrong and disprove of the wiki articles stating it is
 prototype-based, you really should edit them as it must be a
 miss-representation of javascript.

We're not arguing against the articles. We've been arguing constantly
throughout this thread that JavaScript may be prototype-based, but
that does not make it any less object oriented. And I don't think I'm
missrepresenting you at all when I say you've argued against that
point.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-27 Thread liorean
2008/10/27 Anthony [EMAIL PROTECTED]:
 Not once did I hear someone say it was prototype-based. Intact others have
 flat out denied it.

 The question was is it either object or prototype. I merely stated if
 anything it should be seen as prototype, but it does have objects.

Now you're doing that again. What do you mean when you say is it
either object or prototype? Because the sentence as you write it is
nonsensical. If you mean object-based and prototype-based
respectively, then say that. If you mean object oriented, then say
that. If you mean that it has objects, then say that. But saying
javascript is object or javascript is prototype is nonsensical.

For the record, pretty much everyone has said either that it uses
prototypal inheritance - which means the same thing as saying it's
prototype-based - or have said that it is prototype-based.


 Then, it followed with all sorts of garbage from those trying to debunk the
 notion of javascript being prototype. Not once did I say it does not have
 objects. Intact I offered that it does.

it has objects does not mean the same as object oriented. It doesn't
even mean the same as object-based.

You've argued that it's prototype-based rather than object oriented,
and every time we've said that it's both you've argued against us. We
have not debunked that it's prototype-based, in fact we've brought up
the fact it has prototypal inheritance and this is one of the
mechanisms that makes it object oriented several times.
-- 
David liorean Andersson


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

2008-10-27 Thread liorean
2008/10/28 Mathew Robertson [EMAIL PROTECTED]:
 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/

 I hope this helps clear things up a bit.

That's support for classes in the same way C has support for classes
though - you can design them on top of the language, but you don't get
support for it for ordinary language elements or for built in
operators.

You're still not getting around that there's no built in support for
classical inheritance, other than the pseudo-classes that are used in
the ECMAScript spec internally but not for language for us users.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-27 Thread liorean
2008/10/28 Brett Patterson [EMAIL PROTECTED]:
 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.

Yes, it's a registred trademark of Sun, licenced to Netscape once upon
a time as part of a marketing deal including bundling the Java runtime
with Navigator. (Netscape had originally intended to use the name
LiveScript.)


And it would be more correct to say Microsoft implements ECMAScript
than to say they implement JavaScript. They do not implement most of
the Netscape/Mozilla JavaScript additions to ECMAScript.

The name JavaScript is very seldom used by Microsoft. If you read
Microsoft employee blogs and official statements, you almost never
encounter that term. They prefer to either use their own JScript name
or the ECMAScript name.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-27 Thread liorean
2008/10/28 liorean [EMAIL PROTECTED]:
 Yes, it's a registred trademark of Sun,

Actually a Trademark, not a Registred Trademark, apparently.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-24 Thread liorean
2008/10/24 James Jeffery [EMAIL PROTECTED]:
 The language itself is NOT object-orientated, its proto-type based. It can
 be used in an OOP fashion, but this is not true Object Orientation as it is
 in languages such as C++.

Two serious problems with this statement: First, the prototype system
is in fact one of several ways of implementing inheritance in OOP
languages. Second, you're assuming C++ is object oriented. It's one of
several languages that is known to be OOP by programmers while in
actuality it's core is not OOP. Sure, it's possible to use C++ for
object oriented programming, but C++ allows doing things that actually
break object orientation. You can't do that in more OOP languages, for
example JavaScript.

C++ and Java are known as object oriented languages, but they are not
the ultimate in object orientation. There are plenty of languages that
are more object oriented. But they use classical inheritance, and
because JavaScript does not some people have got into their heads that
Classical inheritance == OOP which means JavaScritp != OOP. But that's
a misconception.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-24 Thread liorean
2008/10/24 Nancy Johnson [EMAIL PROTECTED]:
 A bit off topic, but not totally:  are there any free good online
 tutorials (best practices and/or standards based)  to help me learn to
 write javascript?

Well, not a comprehensive learn-javascript-from-scratch course, but
this is a really good place to find tutorials or articles about
separate areas of JavaScript:

uri:http://www.d.umn.edu/itss/support/Training/Online/webdesign/javascript.html
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-23 Thread liorean
 Brett Patterson wrote:
 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?

There's many different things people mean when they talk about object
orientation. If they talk about the Java mode of object orientation,
then JavaScript isn't object oriented but is pretty close. On the
other hand, if they talk about the Self mode of object orientation,
then JavaScript is definitely object oriented, while Java has it's
flaws. There is no single definition that people agree on, only an
arbitrary number of points on a list where no single language uses a
metaphor that covers them all.

Everything in JavaScript is an object. Objects inherit in a run time
delegation fashion from other objects in the prototype chain, a model
inspired by Self. Types are placed on values, not variables, but
everything has a type. Encapsulation comes from closures.

2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:

 JavaScript is commonly referred to as 'object-orientated' but really,
 JavaScript is 'prototype-based'. They do have different meanings, but have
 some similarities...

Class based inheritance is not necessary for a language to be object
oriented. Prototype delegation as mode of inheritance is less common
as language designs go, but it's just as powerful if not more so.

Above all, JavaScript is an object based language.

It has imperative and functional properties, it has a
statement-expression curlies-and-semicolons, it has object orientation
and higher order programming features, it has reified closures and
lexical scope with a few dynamic scope features etc. It's a hybrid
language. But it does have object orientation.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-23 Thread liorean
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 JavaScript objects are augmented with prototype. It should be noted that the
 example you provided also notes that the dot notation is merely syntactic
 sugar - meaning it is just a little bit of eye-candy which provides no extra
 functionality.

 JavaScript objects are merely arrays. This is why they are not real objects.
 Objects and arrays are totally different.

Actually, they are hash tables/dictionaries/maps or whatever word you
prefer to call them by. Anyway, they are sparse string keyed objects
of variable size and not dense integer keyed arrays of fixed size. In
fact, true arrays are only available in JavaScript in the form of
strings, and those are read only.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-23 Thread liorean
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 Forgot to clarify one thing: ECMAScript is fully OO in my opinion, however
 JavaScript is not a full implementation of ECMAScript, unfortunately.

JavaScript is a superset of ECMAScript. If ECMAScript is opbject
oriented, so is JavaScript.

As I mentioned, classes are not necessary or even important for a
language to be object oriented. Prototypal delegation is just one of
several methods of implementing inheritance in an object oriented
language. It doesn't make the language any less object oriented.

Please go have a read through this:uri:http://www.paulgraham.com/reesoo.html

JavaScript fulfills plenty of them.




2008/10/24 Brett Patterson [EMAIL PROTECTED]:
 Well, I read http://en.wikipedia.org/wiki/Prototype-based_programming and
 http://en.wikipedia.org/wiki/Object-based_languages , and I see your points.
 But, for arguments sake, let's say it is not prototype-based. Would it be
 object-oriented, like Java or C++, or object-based?

Depends on what definition you use for either of those terms. Object
orientation? Java and C++ fail to live up to some of the possible
criteria for a language being object oriented. Object based? Do you
mean that every value is an object? If so, JavaScript is that. Do you
mean that it uses prototypal inheritance? Then it is that. Do you mean
it has a limited form of object orientation without inheritance or
polymorphism? If so it is not, because it has those features.

 I read these as well:

 http://en.wikipedia.org/wiki/Object-based

 and

 http://en.wikipedia.org/wiki/Category:Object-based_programming_languages

 What's worst is is that now I am confused. This seems too contradictory,
 based on the articles linked.

That's because the definitions are fuzzy and broad. A language is
better described by what type of programming it facilitates than by
what it can be considered to be, anyway. JavaScript uses prototype
delegation. That means that properties are looked up in the object
itself, and then in the prototype of the object, and so on untill the
top of the prototype chain has been reached. It's a mode of direct
implementation-to-implementation inheritance. Classical inheritance on
the other hand sets up a chain or tree of classes, and objects are
instances of those classes. In other words objects do not inherit
directly from other objects but rather from this chain or tree of
classes - a template chain if you want, though in some of these
langauges the word template means something different. These languages
typically also have a type-to-class correspondence and a deep type
hierarchy system. Some have a separate interface scheme that is about
object and function signatures connected with the type system but that
does not allow code inheritance.
Some have only this and no implementation inheritance mechanism.
-- 
David liorean Andersson


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



Re: [WSG] JavaScript clarification please

2008-10-23 Thread liorean
 2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 Forgot to clarify one thing: ECMAScript is fully OO in my opinion, however
 JavaScript is not a full implementation of ECMAScript, unfortunately.

 liorean wrote:
 JavaScript is a superset of ECMAScript. If ECMAScript is opbject
 oriented, so is JavaScript.


2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 A 'superset' of ECMA3 which is not fully compliant. Right...

Every language has it's implementation holes where the spec and
implementations disagree. However, JavaScript as implemented in the
SpiderMonkey engine is in fact a full implementation of ECMAScript
except for a few mostly minor fringe issues (most of them bugs, a few
of them spec bugs, some reality-trumps-specification issues). So are
Futhark, JavaScriptCore and V8 also. JScript is a bit further off, but
it's not extremely far off.

Go on, try to find a pure ECMAScript feature that is not implemented
in mentioned engines. There are a few, but I bet you'll have to try
pretty many things before you find one. And none of them are about a
whole major feature being broken.
-- 
David liorean Andersson


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

2008-01-21 Thread liorean
On 15/01/2008, Keryx Web [EMAIL PROTECTED] wrote:
 I know Opera have E4X in the works at some level
 http://www.codingforums.com/showpost.php?s=a9dfc400dfd427203a99487bd4ea29d9p=448007postcount=10

That comment's based on the the fact that Opera resolved my RFE for
for each looping as fixed, and for each is part of E4X. It's a
very long step to derive the assumption Opera have E4X in the works
from that, however. There's tons of uses of for each looping, and
implementing for each is cheap if you're aiming at creating an
internal structure that will be able to implement ES4 enumerators
efficiently.

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

Well, you might want to read what Jeff Walden says about Mozilla
implementing E4X at
uri:http://www.webstandards.org/2008/01/16/whats-the-best-test-for-acid3/#comment-59499

 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?

With any luck, it will be E5X (well, it's a better name than E44X...)
by then, will work well together with ES4, and have several integrity
and interoperability problems fixed.



On 15/01/2008, David Storey [EMAIL PROTECTED] wrote:
 I can't comment officially on support for ECMAScript 4, but we do
 have people that are involved in the ECMAScript meetings (such as at
 http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006),
 and we do strongly believe in implementing standards.  We also have
 an article on Dev Opera from our lead javascript engineer on why he
 loves ECMAScript4 - http://dev.opera.com/articles/view/why-i-love-
 ecmascript-4-real-decimals/ .  So you can take those as hints that we
 plan support sometime in the future.

E4X is not part of ECMAScript 4, it's an extension to ECMAScript 3. A
slightly broken one, at that.


To quote myself in a mail to one of the Opera volunteer mailing lists,
editing out the quoted Opera staff:
 If you ask me (which you haven't...):

 - E4X isn't that very useful unless it cooperates seamlessly with the
 DOM, so that we can use it to manipulate document trees in place. This
 is not the case in the Moz implementation, and that level of E4X is
 simply not worth it for developers.

 - ES4 though - I can imagine a few of the new features being popular,
 but them being relevant for developers would require pretty much all
 browsers to have implementing them as a high priority issue. I'm
 particularly interested in features like true arrays, true
 dictionaries, the new number types and the scope improvements from
 block scope and namespaces.

 - Most interesting for a developer is those changes that can be
 emulated if not present, that doesn't need a use only if this support
 is present switch like a version=#.# attribute on the Content-Type -
 that is, mostly standard library stuff. This simply because those can
 be utilised in current code with only minor headaches, unlike any of
 the syntax additions.

I'd say Opera would do best spending developer resources:
1a. Matching the syntax/semantics extensions of Mozilla JavaScript
1.6-1.9, with array comprehensions, let blocks, let expressions etc.
1b. Implementing standard library only fearures. (.hashcode property
on all values is an example I'd like to see here)
2. Implementing the features of ES4 in order of what is perceived to
give most benefit to web developers with some kind of opt-in flag รก la
application/javascript;e4x=1.
3. And maybe last, E4X.
-- 
David liorean Andersson

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

Re: [WSG] Opera files antitrust against MS: standards one part

2007-12-14 Thread liorean
On 14/12/2007, Al Sparber [EMAIL PROTECTED] wrote:
 No offense, but (imo) anyone who believes what you just wrote is extremely
 naive. While all web developers want standards conformance (whether they
 admit it or not), an industry with multiple browsers is not a healthy
 industry. No 2 browsers are alike. Every browser has quirks, anomalies, and
 bugs. What you (Opera) need to spend your idle time doing is coming up with
 a means for web developers to deploy fixes for your bugs. Something similar
 to Microsoft conditional comments.

Isn't that effort more well spent in actually fixing those bugs,
instead?  The goal should IMHO be all browsers supporting the same
HTML/XHTML/XML/XSLT/CSS/JS/DOM/SVG/PNG/whatever without having to
write something specifically to each browser. Reducing the disparities
is a better way to go.

Developers don't WANT to send separate style sheets or scripts for ie.
Developers want ie to get fixed so that it supports those original
style sheets and scripts that are already supported by everyone else.
Op is close enough to the standards and to the other browsers that
they won't break particularly much code out there by fixing those bugs
that are actually bugs. For ie, the situation is different since
fixing those bugs would actually break terribly large amounts of
present code. That's why ie needs conditional comments and compliance
mode switches when other browsers don't.

 Then spend time convincing your compadres
 at Mozilla and Apple to do the same thing. Once you admit that you produce
 bugs, you'll have done a good deed... a noble deed. Then you can go about
 suing and whining all you want. Or do you believe that your browser is
 perfect?

In which way is it better to let developers send code specifically for
fixing a bug, which creates a dependency of that code on the bug in
question, than fixing the bug? If such dependencies are created, they
make it harder to actually fix bugs.
-- 
David liorean Andersson


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



Re: [WSG] Re: WSG Digest

2007-11-29 Thread liorean
On 29/11/2007, Robert Love [EMAIL PROTECTED] wrote:
 Could use JavaScript to number your paragraphs: http://signified.net/test/

Another alternative is to use disjoint ol elements with start
attributes (or alternatively first child li element with value
attribute). Both these attributes are deprecated in HTML4.01 but
really ought not be since they convey semantics that are inherent to
the document structure and aren't purely presentational. It's likely
they will be un-deprecated in HTML5.
-- 
David liorean Andersson


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



Re: [WSG] document.getElementById slow?

2007-10-06 Thread liorean
On 05/10/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hi Simon,

 Direct access will always be faster, here's how the methods work:

 getElementById has to recurse through every child element (the approach of
 the recursion may vary from browser-to-browser) until it finds an element
 that matches the id and then it breaks out of the loop and returns the
 element.

I'm pretty sure browsers speed optimise getElementsById so that it's
an O(1) algorithm. In other words, the browser doesn't traverse the
DOM. But don't take my word for it, do some tests. (Say you have a
document with say 10 nodes, and the element with id at the end, and a
document with 10^6 nodes, and the element with id at the end.) Also
you could try another test, whether the speed of looking up a single
id in the document with 10^6 nodes, and looking the same id when every
node has an id. The algorithm used may be O(n) over the number of
nodes with id. The algorithm could also be O(n) over the number of
preceeding nodes. However, I think no desktop browser could afford the
last case.

 Directly accessing the elements using dot notation is less flexible
 because it will only work with a specific html structure, but there's no
 looping so it's a O(1) complexity algorithm (ie very fast), whereas the
 getElementById algorithm gets increasingly complex as the DOM gets more
 complicated.


Do you have any tests showing this? I'm pretty sure you're wrong about
getElementById having to traverse the full DOM.
-- 
David liorean Andersson


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



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

2007-08-16 Thread liorean
On 16/08/07, Keryx Web [EMAIL PROTECTED] wrote:
 CSS considers only element nodes to be children or siblings. The DOM
 does not.

Actually, selectors considers ONLY elements, never text nodes or
entity references (or comments, or PIs, or CDATA blocks or whatever).
Selectors work on the element tree only, the DOM works on the node
tree.

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

Well, the DOM has drastically different uses than selectors have -
selectors are used to layout containing boxes and style them and their
contents - in other words selectors only need to deal with the
containing boxes, never the actual content. But the DOM needs to be
able to manipulate the full node tree for many reasons - it needs to
be able to deal with the full content, to be able to place elements
and text nodes in correct order as content, not as containing boxes.

 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:

Actually, for specific applications such as HTML, the program building
a DOM is not agnostic about content models. So, in other words for
HTML leaving whitespace out from element content should not be problem
for MOST content models. There are exceptions though: Elements with
both inline and block content models. So in order to both make sense
and be internally consistent, having whitespace text nodes is probably
better than only being able to throw them out in some cases.

 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.

I'd say the Selectors spec makes it pretty clear what it means. Let me
give you an example:


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

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

The spec clearly states no element children, which means non-element
children are not included.


 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.

They are from a *Selectors* point of view. As stated, selectors work
on the element tree and not the node tree. As you surely know, the
WebAPI WG have been making a DOM API for Selectors.
uri:http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8
-- 
David liorean Andersson


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

2007-08-11 Thread liorean
On 11/08/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 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.

The HTML 5 WG have not only a non-SGML serialisation for text/html as
one of their chartered deliverables, but also an XML serialisation
that is intended to replace XHTML1.0/1.1.


See the HTML WG charter: http://www.w3.org/2007/03/HTML-WG-charter

2. Deliverables
2.1 New publications and Milestones
There is a single specification deliverable for the HTML Working
Group, the HTML specification, a platform-neutral and
device-independent design with the following items in scope:
*  A language evolved from HTML4 for describing the semantics of
documents and applications on the World Wide Web. This will be a
complete specification, not a delta specification.
* An extensible, serialized form of such a language, using XML.
* A serialized form of such a language using a defined, non-XML
syntax compatible with the 'classic HTML' parsers of existing Web
browsers.
* Document Object Model (DOM) interfaces providing APIs for such a language.
* Forms and common UI widgets such as progress bars, datagrids,
menus, and other controls.
* APIs for the manipulation of linked media.
* Editing APIs and user-driven WYSIWYG editing features.


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

Elements that behave like block level elements, I'd say.
-- 
David liorean Andersson


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



Re: [WSG] Usefulness of JSDoc

2007-07-25 Thread liorean

On 25/07/07, Keryx Web [EMAIL PROTECTED] wrote:

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?


It's a pretty good idea, but with many of the same arguments against
it as for JavaDoc. But if you ask me, it's not the right tool. A tool
based on JavaDoc will miss some fundamentals of ECMAScript, especially
with ES4 coming soon.

Some examples:
- In a world where both class-based inheritance and prototype-based
delegation exist, both must be distinct. A constructor function, an
interface and a class do not represent the same relations, and do not
work in the same way. This is true also for ECMAScript 3 which doesn't
have class-based inheritance, because implementations have
environments that use class-based inheritance. (E.g. in Mozilla the
implementation of the HTMLElement interface is placed on the direct
implementor class. Overriding properties on HTMLElement.prototype will
not work when the actual implementation lies on HTMLSpanElement class)
- It doesn't make distinctions where distinctions should be made. A
parameter is not the same as an argument.
- It fails to take the closure concept into consideration, together
with the privacy facility it provides.
- It fails to take the fact there are three different kinds of object
typing that can be used into account:
   * There are primitive types/value types (number, boolean) and
compound types/reference types (objects, functions) and a primitive
type with copy-on-write semantics (string).
   * There are classes (String, Object, Number, Array, one each for
most DOM interfaces etc. )
   * There are constructor function/prototype chains (Which are NOT
the same as the above classes)


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


For several reasons. One, I believe, is that autogenerating
documentation has not caught on in the client side web dev world.
There are very few large libraries for ECMAScript compared to other
scripting languages, probably because of the entirely different
environments the code lives in: The code is actually sent over the
wire in raw form. You want to minimise the weight of the sent code, so
you don't want to send documentation in the form of comment systems.
(You can use a compilation step here to remove dead weight but keep
the original in fully commented form, of course - compiling to
minimised ECMAScript). A compiled language doesn't have this
restriction, so for example Flash or Java will have entirely different
models for commenting. And server side languages don't send code at
all, they just send results. The code size server side has entirely
different impact  because of that.


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


The perspective difference is quite a lot of the reason, I feel.
Different considerations give different behaviour.
--
David liorean Andersson


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



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

2007-05-29 Thread liorean

On 29/05/07, Alastair Campbell [EMAIL PROTECTED] wrote:

On 5/29/07, David Dorward [EMAIL PROTECTED] wrote:
 Because, in an HTML document, an XHTML style img tag unambiguously
 means An image element followed by a greater than sign.



I still can't see where it says that in the spec, do you need to know
the SGML spec as well?


Just in the same way you can't know XHTML if you have no knowledge of
XML, you can't really know HTML 2-4.01 with no knowledge of SGML. You
don't need to know all of SGML however, just the subset that is used
for HTML.


It seems strange that the closing slash is
taken as the close, rather than the greater than sign, is that in the
HTML spec somewhere?


Yes, in the SGML declaration.


Since this is either ill defined or not defined in the HTML spec so
far (unless WHATWG tackled it?), I'd suggest that the method implied
by XHTML compatibility guidelines might be a more suitable reference
in future?


Or the mechanism specified in the HTML 5 draft. But that's not even a
WD yet, so it'll have to wait.


 the construct is valid and the
 validator should not claim otherwise. It just doesn't mean what the
 author intends.

Given the mis-match in meaning that does not produce an error, surely
it's something that should change then?


HTML 5 will change it by no longer specifying that HTML is SGML.



And just for fun, let me give you an example of three documents:
uri:http://liorean.net/samplelayout.html
uri:http://liorean.net/sgml-goodness.html
uri:http://liorean.net/xhtmllayout.xhtml

All of them are valid documents and except for DOCTYPE, XML prologue
and XHTML namespace the document they describe is identical.
--
David liorean Andersson


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



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

2007-05-29 Thread liorean

On 29/05/07, Alastair Campbell [EMAIL PROTECTED] wrote:

On 5/29/07, liorean [EMAIL PROTECTED] wrote:
  It seems strange that the closing slash is
  taken as the close, rather than the greater than sign, is that in the
  HTML spec somewhere?
 Yes, in the SGML declaration.
Which someone linked to earlier, and I still can't translate to see
anything on forward slashes... is there actually an SGML spec?


Yes. Linking it probably won't help you though. You'll soon understand why:
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=16387scopelist=

More useful would be the SGML Handbook or some summary site, such as
uri:http://xml.coverpages.org//sgmlsyn/contents.htm


You'd
have thought it would be linked to from here:
http://www.w3.org/TR/html4/intro/sgmltut.html
or googlable with SGML spec, but no such luck.


Well, I got more than enough matches on SGML and Standard.
--
David liorean Andersson


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



Re: [WSG] Wikipedia article help wanted

2007-05-14 Thread liorean

On 13/05/07, Keryx Web [EMAIL PROTECTED] wrote:

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.


Doing what I can on that already, making a suite of test cases for the
standards library purely based on the ECMA-262 3ed spec. (I don't
trust any standards support table for ECMAScript that I've been able
to find. None of them have nearly enough tests to cover the full
functionality of complex functions like Array.prototype.splice and
ilk.  For example, Array.prototype.push is broken in a minor way in
all current engines, in a way that can crash at least all Gecko based
browsers.)
Since wikipedia doesn't deal with original research I'll be hosting
that testsuite on my own domain. However, making tests for every
ECMAScript standard library property isn't fast work, especially since
I want the test suite to have zero false positives.

I've also been doing some work on trying to present syntax-semantics
in a way that lends itself to a SUCCESS/FAILURE/CRASH/PEG result on
each feature, but that's trickier...



If anyone is interested in helping me writing test cases for that
testsuite, just send me a mail.
--
David liorean Andersson


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



Re: [WSG] input name and id

2007-04-19 Thread liorean

On 16/04/07, Nick Fitzsimons [EMAIL PROTECTED] wrote:

Name and ID serve two different purposes. ID is used to identify the
element's node in the document [1]. Name is used to identify the
element's value in the form submission posted back to the server [2].

OTOH, according to the HTML 4.01 Strict DTD, name is #IMPLIED, not
#REQUIRED, so the book is incorrect. [3]


The book is correct. It's a question of HTML having rules that DTD
can't represent. In this case, that input elements can be form
controls or form functionality (i.e. type attribute has a value of
submit or reset). The name attribute is required on form controls but
not on form functionality. The DTD format doesn't allow this type of
granularity however.

In other words, just because something is valid according to the HTML
DTD doesn't mean it's valid according to the HTML specification.
--
David liorean Andersson


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



Re: [WSG] input name and id

2007-04-19 Thread liorean

On 19/04/07, Nick Fitzsimons [EMAIL PROTECTED] wrote:

A DTD is perfectly capable of specifying that an attribute is
required: it uses the syntax #REQUIRED. The spec for the name
attribute of the input element states that it is #IMPLIED, not
#REQUIRED, therefore it is not correct to say that the name is required.


Yes, that is true. However, a DTD is not capable of stating that the
attribute is optional ONLY when the value of the type attribute is
reset or submit. The attribute is required if that is not the case.


The name is  _necessary_ for a control to be a successful control,
but the book is still wrong if it states that the attribute is
_required_ by the spec.


You're right on one point. If the book states that it's required for
ALL input elements, then the book is wrong. However, saying it is
optional is equally wrong, because it isn't optional for form control
input elements (i.e. all type attribute values other than reset and
submit, including the value button, entirely independent of whether
the form control may be successful or not).
--
David liorean Andersson


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



Re: [WSG] Out of Office AutoReply: digest for wsg@webstandardsgroup.org

2006-03-08 Thread liorean
On 08/03/06, Felicity Farr [EMAIL PROTECTED] wrote:
 I am currently out of the office and will return Tuesday 14th March. For any
 urgent enquiries please contact [EMAIL PROTECTED]

And sending that you just spammed a mailinglist...

If you are subscribed to any mailing list, make sure it is either
whitelisted or otherwise excluded from the autoresponder. See
uri:http://web-graphics.com/mtarchive/001730.php
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] IE7 - The Good the Bad and the Ugly

2006-03-03 Thread liorean
On 03/03/06, Stephen Stagg [EMAIL PROTECTED] wrote:
 I don't know how many of you have tried IE7(currently Beta 2) yet,
 but It has a number of 'features' that could cause some issues /
 solve some issues, I thought I would list those that i've experienced
 and see if I can get some comments on them:

Technically it's not ie7b2. It's the ie7b2p  (p for preview). That
means a b2 might be released that fixes some of the issues in the
current b2p, so make sure you always specify that it's the preview
you're talking about, since there might be a release of ie7b2 to
follow. Hopefully Microsoft will realise the risk of confusion and
make the next release ie7b3, but I wouldn't count on that.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Today's lesson: Respect - be courteous up or leave

2006-02-09 Thread liorean
On 09/02/06, russ - maxdesign [EMAIL PROTECTED] wrote:
 Russ
 Miss Manors

Why do I get this sudden urge to humm The Commodores (She's a) Brick House?


And, and please do something similar for posting ettiquette. Just
looking at replies to this post  there's two top posts which quote
your entire message without any trimming...
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.

2006-02-08 Thread liorean
On 08/02/06, Stephen Stagg [EMAIL PROTECTED] wrote:
 Why do we need an HTML 5? Can't we dispose of HTML and just use
 styled XML in the future? It would be one helluva way to enforce
 standards, and we wouldn't have all this wrangling over exactly which
 element to use.  HTML in itself is not a good example of an XML
 doctype because the paragraph markup does not lend itself to proper
 hierarchic layout.  the heading tags should be able to be subsets of
 a paragraph, for example.

Well, it's a question of attaching semantic meaning to the structure
of the data. XML has zero semantic meaning for elements. In XML,
hdusdlejncy wiakhjsem=blah has exactly the same semantic meaning
as a href=blah. That is, no meaning at all. We need some kind of
attachement mechanism for semantics. This is provided in two possible
ways, either externally by the mimetype or internally by namespaces.

XHTML, SVG, RSS, Atom etc. can all be summarised as sets of semantics.
And by all means things closer to the heart of XML such as XLink,
XInclude, XML Schemas, XLS-FO, XLST etc. too.

What we really want to do when we create documents isn't usually just
to provide a structure for data to present in a certain way. We want
to convey some kind of meaning. The meaning can't be conveyed by CSS.
It's possible we could create a semantics attachment model, but
semantics on the whole aren't easily representable for computer
understanding. A much easier solution is to use specific sets of
semantics, which we attach by namespaces or mimetypes. All consumers
can then see if they support the mimetype or namespace, and attach the
semantics of that set of semantics to the underlying structure. In
fact, consumers of XML that don't know the semantic set of a namespace
are still able to say that the meaning is described by that namespace,
even if they don't know in particular what that meaning is.

These sets of semantics are of course the XML applications such as
XHTML1 or XHTML5.

 The focus would then shift to CSS and the different display-types
 that can be defined for ANY tag.  Microformats and Micro-Namespaces
 could then  be used to allow true semantic delivery.

But really, you need a namespace to attach meaning in XML. XHTML is a
known and widely implemented namespace. Why not use this namespace as
base for extended semantics, instead of introducing new namespaces for
it? And as for microformats, those are actually just extensions of the
semantic set of this very namespace, or extensions of other sets of
semantics. You can't attach semantics to XML without these tools,
really. Microformats are just semantics attached to normally
semantically indifferent constructs in an already existing set of
semantics.

 I take it this has been suggested before, so what are the arguments /
 counter-arguments ??

Arguments for using plain home made XML is that you might want higher
granularity and specificity of semantics than provided by preexisting
XML applications. But really, to get that you essentially need to
create that set of semantics and assign it to a namespace. Just naming
something footnote or navigation doesn't mean it gets the semantic
meaning of being a footnote or navigation. Nor does it convey any
particular definition of how to handle that if no presentational or
behavioral hints exists explicitly in the document, because the
defaults on not-strictly-semantical aspects are also part of the
semantic sets (In my view, at least. Which isn't neccesarily canon...)

Counter arguments against it I think I've already mentioned.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Which unit is better for web site font size?

2006-02-01 Thread liorean
On 01/02/06, Brian Cummiskey [EMAIL PROTECTED] wrote:
 Minh D. Tran wrote:
  My personal preference has always been pt. I've looked at many
  professional source codes and alot of them uses px or % to measure size
  of items (divs, img, etc), em for positioning, and pt for font sizes.
 pt is for PRINT media, not screen.

Wrong. Points are for all devices that operate at different ppi* than
96. Points have a locked points per logical inch resolution of 72.
Pixels vary depending on ppi. So, if a medium has 96 ppi then a 12pt
text will be rendered as 12*96/72=16px. If a medium has 120 ppi, then
the same 12pt text will be rendered as 12*120/72=20px. If a device has
300 ppi, the 12pt text will be rendered as 12*300/72=50px. And the
reverse is also true. That means that 16px text on a 96 ppi medium
will be rendered the same size as 16*72/96=12pt. If a medium has 120
ppi, 16px text will be rendered as 16*72/120=9.6pt, and if a medium
has 300 ppi the 16px text will be rendered as 16*72/300=3.84pt.
...except for the fact that the CSS reference pixel is defined at
about 1/96 inch and not the actual medium pixels, so a smart renderer
that knows about it's medium's ppi might scale it and thus make sure
that 16px=12pt is always true. That knowledge or it's implementation
for that matter is not guaranteed, however.

* Pixels per logical inch, which is about equivalent to dots per
physical inch as is used in print media. Default in Windows is 96
(Windows even calls it DPI), or 120 for large size.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] HTML Numeric and Named Entities

2006-01-11 Thread liorean
On 11/01/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
 liorean wrote:
  Character references refer to Unicode code points independent of the
  document encoding and character set. At least for HTML4 and XML, if
  not for HTML3.2.

 As far as character references in HTML are concerned, they have always
 referred to the Unicode code points since HTML 2.0.

Ah. I just saw

 BASESET  ISO 646:1983//CHARSET
   International Reference Version
   (IRV)//ESC 2/5 4/0
 BASESET  ISO Registration Number 100//CHARSET
   ECMA-94 Right Part of
   Latin Alphabet Nr. 1//ESC 2/13 4/1

in HTML3.2 and

  BASESET  ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with
implementation level 3//ESC 2/5 2/15 4/6

in HTML4.01 SGML declarations and assumed the first one (ISO-646) was
ANSI, the second one (ECMA-94) was the extended 8-bit characters
(latin-1) and the third one (ISO-10646) was Unicode. This assumption
was wrong?

 See my article:
 http://lachy.id.au/log/2005/10/char-refs
 (take note of the comments too, which contain a few corrections)

I read it months ago :)
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] HTML Numeric and Named Entities

2006-01-10 Thread liorean
On 11/01/06, Kat [EMAIL PROTECTED] wrote:
 Is it safe to use the named references that formerly refered to the control 
 characters?

Multi level answer here:
- text/html: Should be perfectly safe.
- application/xhtml+xml: Should be, but isn't, safe except for the
five named entities of XML. Use decimal or hexadecimal character
references instead.
- application/xml: Only safe in validating user agents. Which doesn't
include browsers. So, use decimal or hexadecimal character references.

 If you have used these named references in the past, so long as you 
 have(update to) the correct character encoding,
 do these automatically refer to the correct entities?

Character references refer to Unicode code points independent of the
document encoding and character set. At least for HTML4 and XML, if
not for HTML3.2. Named entities just map to the corresponding
character references.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards

2005-12-10 Thread liorean
I feel you are forgetting a number of things.

- Response times:
Response times are every bit as important to Google as bandwidth usage
is. A user should never have to wait for the Google page, or the
Google search results. Ever.
CSS and JavaScript in separate files means the browser needs two
roundtrips to server more than currently. If rendering relies on CSS,
this means unreliable response times and inevitable slower percieved
loading (Try a 14.4 modem on phone lines with high interference and
75+% packet loss - those can make any page seem like it takes an
eternity to load). And JavaScript loaded as a separate file means
unrealiable script triggering. We wouldn't want to throw an error
report in the face of our users just because they don't have the
script loaded yet, do we?

- Hidden bandwidth consumption:
Google pages, especially the main page, are pretty light weight. Which
means the HTTP headers are a considerable part of the bandwidth
consumption. You double the amount of HTTP headers to send if you add
two external references - both requests and responses.

- Obvious bandwidth consumption:
We have unneccesarily increased bandwidth consumption from the script
and link elements required to reference these new files, as well as
from the doctype needed to make the HTML valid.

- Localisation:
Google has within all probability made their pages so that minimal
changes are required even to languages and scripts considerably
different from English. This has to be considered for any remake with
semantical markup, including the issue of the next point.

- Serialisation:
Not only do we want our content to be laid out the same in CSS and
JavaScript enabled browsers. We also want to retain the current
layout/serialisation for the content in browsers with bad or no CSS
support, with terminal window textual browsers, screen readers or
braille interfaces. Google may throw ugly code at us, but it isn't
inaccessible as it is. This includes things such as not laying the
Web/Images/Groups... out as a horizontal list instead of a single line
when you have no CSS support.

- Dynamic elements:
Things such as being logged in/not logged in, having Google Desktop or
not, sponsored links, search listings etc. all need be take in
consideration.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] *Why* doesn't Google validate? was New logo scheme was talking points for standards

2005-12-10 Thread liorean
On 10/12/05, Christian Montoya [EMAIL PROTECTED] wrote:
 See Rimantas' version... I think you are focusing too much on the
 specific implementation of standards, and not the simple fact that if
 Google used standards, they would save a lot. At least Rimantas
 thought ahead and solved these problems by putting the CSS in the
 header, but let's not all bash Matt for not doing that.

Actually, when I started writing that, Rimantas hadn't posted his
first entry yet.

 Also see my post on GIF vs. PNG.

Well, support for gen  5 browsers maybe could speak against PNGs.
Google have to consider a wider audience than most other major sites.
Otherwise, yeah, it makes sense to use PNG for the size reduction.

 What? I would rather modify the standards version than the original.
 The original uses tables, which means you have to add TD's every time
 you want to add another link, which are much heavier than adding LI's.
 Also, the standards version allows the Google codemonkeys to cut and
 paste the CSS, and then just edit the markup to reflect the
 language/localisation.

Maybe, but it's a consideration that hadn't been mentioned yet when I
started writing that. Actually I was more thinking about the way
actual search listings, sponsored links and results overview are laid
out in different languages. How do they handle vertical scripts, for
instance?

  - Serialisation:
  Not only do we want our content to be laid out the same in CSS and
  JavaScript enabled browsers. We also want to retain the current
  layout/serialisation for the content in browsers with bad or no CSS
  support, with terminal window textual browsers, screen readers or
  braille interfaces. Google may throw ugly code at us, but it isn't
  inaccessible as it is. This includes things such as not laying the
  Web/Images/Groups... out as a horizontal list instead of a single line
  when you have no CSS support.

 Huh? The bottom line is saving money, accessibility or serialisation
 is not so important. I would say it serializes just fine in the
 standards version anyway.

Might very well do. Does the content before the search box to take so
small space as to allow an 80x25 text browser to show it without
scrolling? That's about as much requirements I think one can have on
this issue in particular. Keeping it to a single page also in text
browsers does wonders for usability in such.

  - Dynamic elements:
  Things such as being logged in/not logged in, having Google Desktop or
  not, sponsored links, search listings etc. all need be take in
  consideration.

 How? What does that have to do with it?

Consider the entire www.google.com site. Or at least the search part
of it. You probably want to create one stylesheet file and one
javascript file for the entire thing, probably sent compressed if
client supports it, so it gets cached and not requested again in that
browser session.

Also, how many users access the main page once but searches several
times in a row, or move beyond the first listing page? How many access
it from the Google bar or browser search fields instead of coming
through the main page?  The main page is just a part of the
application, not the whole thing.

These considerations probably make CSS layout an even better choice
for reducing bandwidth consumption.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Konquerer becomes the 2nd browser to pass Acid2

2005-11-30 Thread liorean
On 01/12/05, Jason Foss [EMAIL PROTECTED] wrote:
 Safari was the first wasn't it?

Yep. And iCab 3 developer builds reportedly support it too.

 Hope a Windows browser manages that soon... :(

Konqueror on Win32 isn't entirely unthinkable. The rest?

Well, Mozilla tends to have quite long development cycles, and they
just ended one.
Chris Wilson stated on IEBlog that IE7 will not pass Acid2 when
shipping, which would mean Acid2 in iew is deferred to yet future
releases.
Opera is close already, only having problems with the eyes part. So my
bet would be on Opera being the first Windows browser to pass it.
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] Validation error question for XHTML Strict

2005-05-06 Thread liorean
On 5/6/05, tee [EMAIL PROTECTED] wrote:
 But it is in the div
 
 Example:
 div id=form
 form method=post action=form.cgi
 input type=hidden name=postmode value=QUANTITYBOXES /
 pblah blah blah /p
 div class=twoCol
 labelinput type=text size=2 name=quantity1 / item name/label
 labelinput type=text size=2 name=quantity2 / item name/label
 /div
 /div

You misunderstood that a bit: It must be the direct contents of one of
the elements listed - no elements in between.
You currently have 

div  form  input

But the input need to be contained in one of the listed elements - for
example like this:

form  div  input

It's a question of direct parent, not ancestor.
-- 
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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



Re: [WSG] usage of new entities in dtd's

2005-04-07 Thread liorean
On Apr 7, 2005 8:41 PM, Alan Trick [EMAIL PROTECTED] wrote:
 I'm just curious if any popular browser would display this page properly
 http://www.tarunz.org/~vassilii/html-is-an-sgml-dtd.html
 I though Moz would, but it disapointed me.

I thought it was common knowledge that no browser in common use (and
by common use I include every browser that has ever been above 0.1% in
usage statistics for the net) uses a true SGML engine. HTML as
employed on the web requires a tagsoup parser, or the majority of all
pages would experience problems. There are just too much error
correction that needs to be done in the HTML engine to allow a browser
to use a true SGML engine.

Look for example on all XHTML sent as HTML. The element/ syntax has
a different meaning in SGML. You can have a look at
uri:http://liorean.net/sgml-goodness.html for an example of a
perfectly valid HTML 4.01 Strict document that no browser in common
use handles due to their lack of SGML parsing.
-- 
David liorean Andersson
uri:http://liorean.web-graphics.com/
**
The discussion list for  http://webstandardsgroup.org/

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