Re: [whatwg] scripts that remove focus from links during document navigation

[Jim Ley]

On 20/09/06, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:



This coding is very common because IE adds a small outline border to
focused links. Authors who do not like this will blur links when they are
activated to avoid this cosmetic issue. (Mea culpa: I've done exactly this
myself in sites I coded as a newbie, for that very reason.)


The reason being you'd not heard of the hidefocus attribute :-)  or
onfocus="this.hideFocus=true" if you want to be free.


In Opera, when keyboard navigation hits this link, focus is removed. Thus
the link can not be activated from the keyboard and navigation may have to
start from the top of the document again.


Right so ignore it.


We need some prose in a spec that allows a user agent to ignore blur() for
accessibility reasons.


Why do you?  there's no prose in any spec which says you have to
support any script etc., and if there is, I would encourage you to
break it anyway, obviously anything that harms accessibility to your
users is something that it is your duty as a web-browser company to
not do.

I can appreciate you'd rather point to some other place and go "look,
look they said it was okay", but in that case you already have it UAAG
is fine for that.  I don't think it's good to spell out and make
specifications even longer just to give you somewhere to point pretty
deluded authors.


'scripts must not alter focus-related issues in a way that hinder keyboard
operation, and user agents may override any such use of focus-related
scripting operations.'


I don't like this, it doesn't define hinder well enough for a MUST,
can't you just take it as read that you're allowed to?

I can't foresee any realistic collateral damage from actually blocking
the behaviour - but if that genuinely is the case, then removing blur
entirely would be a more appropriate solution.

Mostly though I encourage you to continue in the vein of promoting
your user, rather than hiding behind spec's, you've done it so well to
date!

Jim.

Re: [whatwg] Persistent storage is critically flawed.

[Jim Ley]

On 28/08/06, Shannon Baker <[EMAIL PROTECTED]> wrote:

I accept tracking is inevitable but we
shouldn't be making it easier either.


You have to remember that the WHAT-WG individual is a Google employee,
a company that now relies on accurate tracking of details, so don't be
surprised that any proposal makes tracking easier and harder to
circumvent.

It's probably a design requirement, of course like all WHAT-WG stuff,
there is no explanation of the problems that are attempting to be
solved with any of the stuff, so it's impossible to really know.

Jim.

Re: [whatwg] Dynamic content accessibility in HTML today

[Jim Ley]

On 14/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:

I hadn't considered putting an alt text on it, because the image's
function is described by the role itself.


It's got nothing to do with it's function, you've got an image in the
page, to be accessible a user has to be able to find out what the
image is - unless it's purely decorative where you could have an empty
one - but this is a functional image - so it must have an ALT, there
is no discussion


Does the image for a checkbox using a standard html need an alt text?


The standard HTML checkbox is not an image, it's a checkbox...

So, I'm not sure why you stopped looking after
that


Because you claimed something was truly accessible, when you'd not
made the first step of ensuring images have ALT text, say, here's an
example which makes  an image used as a checkbox accessible to some
screen readers, and if you put in a lot of other work you could make
it accessible to other people would've been okay, but you didn't you
chose to claim it was truly accessible.


It seems like something else is bothering you about my message.


Just the all too common claim of accessibility authors not actually
increasing accessibility just moving it to a different group having
problems.


In any
case, I'm only here as a fellow colleague providing food for thought. I
hope that's not a problem.


Oh definately not, your work is very useful!  Just don't make the
mistake of over-claiming what you do, the examples are not accessible,
they aren't unfortunately.


The core is, accessibility is important and
no doubt there are places where whatwg does things better,


I don't think the what-wg does a good job of accessibility at all,
there are some good ideas certainly, but there's also a lot of badness
due to the degrading to a whole heap of script that's required in a
number of areas.

Your work on Role is very good, and I'd certainly encourage you to
stay participating in the what-wg.

Jim.

Re: [whatwg] Dynamic content accessibility in HTML today

[Jim Ley]

On 14/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:

What browser/screen reader are you using?

You need at Firefox 1.5 or later and Window-Eyes 5.5 or later or JAWS 7
or later.


I'm not using a screen reader, accessibility is about not requiring a
particular technology...  Or did I miss a memo?

Cheers,

Jim.

Re: [whatwg] Dynamic content accessibility in HTML today

[Jim Ley]

On 13/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:

So we already have truly accessible DHTML widgets that are
key navigable and usable with 3rd party tools such as screen readers.


Could I ask where these are discussed?  Because things like:
http://www.mozilla.org/access/dhtml/class/checkbox
are certainly not accessible to me (there's a non purely decorative
image that without alt text for example)  Please don't say truly
accessible, when it clearly isn't.

How much trouble would it have been to just go .alt="checked"
"unchecked" ?  I stopped looking beyond that.

Jim.

Re: [whatwg] fullscreen event?

[Jim Ley]

On 11/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

My suggestion would be to have a renderingMode event (or something
like that) which in some way exposes a mediaList of the current
rendering modes (mostly just one). If you go to print preview mode for
example the event is dispatched and the mediaList contains 'print'. If
you go to projection mode it contains 'print' etc.


The issue with this is that we've struggled to find any situations
where there genuinely are multiple modes being rendered
simultaneously, the print preview in IE doesn't (the afterprint
returns immediately and there are no screen updates during the
intermediate times)  So I think we should avoid anything that actually
considers different views being considered available simultaneously,
it's a red herring without implementations, so we can ignore it :-)

Jim.

Re: [whatwg] fullscreen event?

[Jim Ley]

On 10/05/06, Dean Edwards <[EMAIL PROTECTED]> wrote:

On 10/05/06, Jorgen Horstink <[EMAIL PROTECTED]> wrote:
> I just had a little chat with Anne and he thinks a rendering change
> event (ie: before printing, generate a table of contents) will be usefull.
> I think he is right.
>

I suggested onbeforeprint/onafterprint events a while back. It got
shot down. :-(


How disappointing, let's hope the webapi wg look at it... there's
certainly existing implementations to just copy.  They're useful
events.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/21/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Chris Holland wrote:
> > That's where the extra HTTP header would come-in:
> > "X-Allow-Foreign-Hosts": Forcing developers who expose such a service,
> > to make the conscious choice to expose data to the world, what Jim
> > refers to as "OPT-IN".
>
> I believe the usual objection to this (which was raised when I suggested
> something similar) is that some services respond to requests by doing
> something ]

The flaw in that argument is that img.src="..." is equivalent.  If the
initial challenge request is a GET, which it of course the spec can
require.

>- therefore, a model which allows cross-site requests has to
> check that the request is permitted before making it, not before
> processing the result.

Certainly, that's one of the issues with the header approach - the GET
and check for header or check magic URL for an XML doc, then make the
request should be safe from such issues. Both Mozilla dand Flash
already have that deployed and working.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/20/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
>  > Or indeed wrote your script before this JSONRequest was invented.
>
> I think I see where you are confused. A pre-JSONRequest JSON application
> will be using GET, or POST with a conventional POST body.

What exactly is a "conventional POST body"

> JSONRequest cannot generate a GET, so those interfaces are
> safe,

Many webservers will return data in response to a POST even if
expecting a GET, a bug perhaps, but there's no specification which
prevents it.

> and it cannot generate a conventional POST
> body, so those applications are safe, too.

I have lots of applications that POST json to the server, and return
more JSON, for exactly the reason your proposing this interface now.

> If an application is so badly implemented that it accepts dangerous POSTs (we
> already determined that JSONRequest is safer than form.submit in this regard)

Where did we determine this?   Please start sharing your security
analysis, it seems rather lacking to me, so I'm not really prepared to
trust blanked statements of what you've determined.

> So, is this a problem? No. First, JSONRequest will reject the response and not
> return to the script because the Content-Type is not application/json.
> application/json is only now being registered as MIME media type. Legacy
> applications should not have been using it.

_SHOULD_  see, you're relying on perfect systems everywhere, that is
not an appropriate reliance, and as there are other methods - opt-in
methods - that allow cross domain scripting to be done more securely,
I simply don't see the point of not using them, and go for these poor
security methods you're advocating.

Also, someone using a application/vnd.someone.json will likely change
their server configuration to application/json as soon as it's
registered, so legacy apps will be using the appropriate mime-type.

> So, to repeat, JSON introduces no new security vulnerabilities for the legacy
> JavaScript data formats of six years ago.

You just admitted, that it did, so please stop repeating that phrase,
you may want to use a phrase such as "few" or "rare" or "only in
certain situations" are new security vulnerabilities present, but
there are certainly not none, and your refusal to admit this in the
document, when you do here suggests that you do not want your
specification to be reviewed fairly by all concerned.

> I would very much like to see the details of a specific attack in which a 
> legacy
> application which depends solely on firewall locality for its security is
> compromised by JSONRequest.

I have some where all that would be needed is a
application/x--jl-message-result becomes a application/json -
something that is likely to happen (without me knowing) once the the
mime-type is registered.  Of course it's behind a firewall, so I can't
direct you to it, but it meets all of the other restrictions on JSON
you've listed above.  The data protected is pretty innocuous, but I'd
be crazy to think I was the only person doing it, why do you think I
am?

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

> My intention with JSONRequest is to make it minimal because being minimal will
> make it easier to understand and easier to implement correctly.

Making caching behave completely differently for
http://example.org/json.rjs in two different situations is not easy to
understand.

Making caching behave differently for requests made via a different
call are not easier to implement.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/19/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
>  > The mimetype you're defining, because it is new, pretty-much ensures
>  > no existing service behind an intranet could be affected.
>
>  > I could still envision one day developers setting-up JSON syndication
>  > services behind an intranet, not quite grokking the fact that their
>  > data is now accessible from outside of their intranet. Silly, i know
>  > but ...
>
> It is a concern. The only solution to that that I can see is education.

No, the solution is pretty clear, all cross domain activity is
designed to be OPT-IN, just like all other current methods, then
concious effort needs to be made to allow your data onto other peoples
sites.

> A con with JSONRequest is
> that if your are incompetent in determining your authentications, then data 
> may
> leak.

Or indeed wrote your script before this JSONRequest was invented.

Please remove your false and misleading "introduces no new security problems".

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/17/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> > The cache rules are unworkable, please remove these and use standard
> > HTTP methods for suggesting the cacheability of a resource, forcing
> > them to be uncacheable is unworkable w.r.t. to proxy caches and
> > extremely unwelcome within the browser.
>
>   Applications must not cache responses to a POST request because the
>   application has no way of knowing that the server would return an
>   equivalent response on some future request.

Of course the application can know that, that's what HTTP cache
control headers are for, the cacheability of a resource is easy to
advertise, and all browsers should know it.

Please explain your use cases for making no JSONRequest cacheable, it
really is completely silly to me and an absolute deal breaker, I
assume it's because working for yahoo you need not worry about such
things as bandwidth and cost.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/17/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > Please can you provide more information on how raw JSON is available
> > from script elements?
>
> Apologies; it was the Array constructor, and I was slightly wrong in the
> details. Here is the exploit:
> http://www.webappsec.org/lists/websecurity/archive/2006-01/msg00087.html

Yeah, only applies to Array, and I'm of the belief this is a Mozilla
security flaw anyway, hopefully it'll be fixed soon.

Thanks for including the URL in the thread too, illustrates exactly
why there are security concerns introduced with this JSONRequest.

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/16/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Hallvord R M Steen wrote:
> > You are right, if no variables are created one can't see the data by
> > loading it in a  SCRIPT tag. Are you aware of intranets/CMSes that use
> > this as a security mechanism?
>
> That's not actually right. I'm pretty sure this came across a public
> security list, so...
>
> You can override the constructor on the prototype of the Object object
> and get access to JSON objects before the JavaScript engine throws them
> away when it realises they don't get assigned to a variable.
>
> Or something like that, anyway. I can't remember exactly how it worked.
> But I'm pretty sure that it's true that you can get JSON data if it's
> not protected.

I can't reproduce this, in IE and Opera, there's no effect whatsover
playing with Object constructors, in Mozilla there is however it is
not called unless you have an expression:

{chicken:true} // doesn't call it.
donkey={chicken:true} // does call it.

Please can you provide more information on how raw JSON is available
from script elements?

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/16/06, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> > > If you today embed data on an
> > > intranet in JavaScript I can create a page that loads that script in a
> > > SCRIPT tag and steal the data.
> >
> > Could you please describe how exactly?  the contents of remote script
> > elements are not typically available (and if they are it's a large
> > security hole today) unless valid javascript objects are produced to
> > be queried, that is not the case with bare JSON.
>
> You are right, if no variables are created one can't see the data by
> loading it in a  SCRIPT tag. Are you aware of intranets/CMSes that use
> this as a security mechanism?

Yes, I've shipped systems, and seen many others where the only
protection on the internal side is IP based, and use JSON data
retrieved by XHR and new Function'd into JS objects.  It's quite
common in fact.

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/16/06, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> On 3/11/06, Jim Ley <[EMAIL PROTECTED]> wrote:
>
> > Accessing JSON resources on a local intranet which are
> > secured by nothing more than the requesting IP address.
>
> While this is a valid concern I think the conclusion "no *new*
> security vulnerabilities" is correct. If you today embed data on an
> intranet in JavaScript I can create a page that loads that script in a
> SCRIPT tag and steal the data.

Could you please describe how exactly?  the contents of remote script
elements are not typically available (and if they are it's a large
security hole today) unless valid javascript objects are produced to
be queried, that is not the case with bare JSON.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/13/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> > " It provides this highly valuable service while introducing no new
> > security vulnerabilities. "
>
> > is false, please remove it to avoid any confusion.
>
> It would be very helpful if you could list the situations that
>you have determined are lacking.

I did in the paragraph after the part you quoted.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/13/06, Darin Fisher <[EMAIL PROTECTED]> wrote:
> Moreover, if HTTP auth and cookies are not supported, then how does
> someone restrict access to their JSON service?  For example, it is
> common practice to use Kerberos to implement HTTP auth on intranets.

If you know you might be susceptible to the intranet attack, then all
you need to do is use SSL and have the  security within the JSON
string, of course doing this opens you up to seperate problems, and
it's far from easy.

>  I don't think this is a new idea as
> several specifications have been attempted along these lines.  Mozilla
> even implements one of them for its SOAP and WSDL implementation.

Yep, whilst I'm not overly happy with the approach, it's certainly
better than the let's hope people don't know our urls of the above
proposal.

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/11/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> I am proposing a new mechanism for doing data transport in Ajax/Comet
> applications. It is called JSONRequest. It is a minimal communications
> facility that can be exempted from the Same Origin Policy.
>
> You can read about it here: http://json.org/JSONRequest.html

Unfortunately your security analysis is lacking some situations,
Indeed the statement

" It provides this highly valuable service while introducing no new
security vulnerabilities. "

is false, please remove it to avoid any confusion.

Accessing JSON resources on a local intranet which are secured by
nothing more than the requesting IP address.  Indeed you actually skip
over this pretending that there would only be legacy
data/documents/scripts available in such a situation, despite the
number of people who've been shipping such products for 6 years or
more.

In other non security areas, you don't define how the delay product is
reset - is it per window, per host, per instance?  That needs
defining.

The "not ok" needs to be refined to deal with proxy caches that may
return other codes, e.g. 304 or 206.

The Duplex claim is misleading, and you should specifically mention
that if you do use 2 connections, no other content would be
downloadable from the site in a conforming HTTP 1.1 implementation.

The cache rules are unworkable, please remove these and use standard
HTTP methods for suggesting the cacheability of a resource, forcing
them to be uncacheable is unworkable w.r.t. to proxy caches and
extremely unwelcome within the browser.

Most importantly is to actually make it safe to use.

cheers,

Jim.

Re: [whatwg] diffed versions (CVS)

[Jim Ley]

On 3/3/06, Ian Hickson <[EMAIL PROTECTED]> wrote:
> http://svn.whatwg.org/

Excellent, thank you very much.

> Converting the spec to wiki format is not an option while I'm an editor.

Good, Please don't do this even if some new editor came along - which
I don't want either.  SVN is great, a few more dated call for comments
(which would be even harder with a wiki) would be nice too, but not
essential.

Cheers,

Jim.

Re: [whatwg] [wf2] changing the size DOM attribute of

[Jim Ley]

On 2/11/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Quoting Jim Ley <[EMAIL PROTECTED]>:
> > D you mean the bug in Opera 9 that means changing the size of the
> > select selects an entry?  Surely that's just a bug in Opera 9 preview
> > (but not 8.5), changing the size should have no effect on what's
> > selected.
>
> I agree (with the part after the comma of the last sentence). Given that per
> <http://whatwg.org/specs/web-forms/current-work/#select-check-default> the
> option should be selected, it should remain selected when changing some factor
> that has nothing to do with that.

but in your test case, they are not selected, and then become selected
in Opera 9.0 when you give them an invalid attribute - was Opera 9.0
not the behaviour you were looking to standardise too?  (I assumed
that as the Opera 8.5 behaviour was absurd with -1 making it about 40
high)

For me ignoring the invalid DOM change makes more sense that the
inconsistent proposals you're advocating.  The cited part of the spec
linked to above certainly does not say what should happen when a DOM
changes to a single select in any case, it is still undefined even in
the size=1 case.

Cheers,

Jim.

Re: [whatwg] [wf2] changing the size DOM attribute of

[Jim Ley]

On 2/11/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Quoting Jim Ley <[EMAIL PROTECTED]>:
> > I simply don't see the value in standardising the error behaviour here.
>
> Just setting it to 1, which is an appropriate value, does not give
> interoperable
> behavior either. (The selected option is not the same.)

D you mean the bug in Opera 9 that means changing the size of the
select selects an entry?  Surely that's just a bug in Opera 9 preview
(but not 8.5), changing the size should have no effect on what's
selected.

Cheers,

Jim.

Re: [whatwg] [wf2] changing the size DOM attribute of

[Jim Ley]

On 2/11/06, Jim Ley <[EMAIL PROTECTED]> wrote:
> On 2/10/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> > Browsers disagree on what should be selected in such cases. Simple testcase:
> >
> >  <http://webforms2.testsuite.org/controls/select/009.htm>
> >
> > Opera 9 passes that test and I heard Safari nightlies do too. Internet 
> > Explorer
> > and Firefox fail the testcase. Personally I would be in favor of changing 
> > the
> > specification to be compatible with Opera 9 and Safari given that what they 
> > do
> > is sensible.
>
> Why can't this be left undefined? what does it matter to have
> interopable rendering on invalid DOM changes?  Surely forcing code
> changes on anyone is just a waste of implementation time here, not
> updating the page when the DOM is changed to an invalid number is a
> good optimisation?
>
> IE for example simply rejects the update (the size remains at 2), that
> seems like a sensible approach, as does normalizing it to 1.
>
> I simply don't see the value in standardising the error behaviour here.

Oh but if you do, I don't believe the Opera method of having the
appearance of a 1, but a value of a size of 0 or -1 is correct.  If
corrections are made, the DOM should reflect the actual value used -
after all that is the only thing useful to the user.

Mozilla seems to correct -1 to 0 but nothing else.

Cheers,

Jim.

Re: [whatwg] [wf2] changing the size DOM attribute of

[Jim Ley]

On 2/10/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Browsers disagree on what should be selected in such cases. Simple testcase:
>
>  
>
> Opera 9 passes that test and I heard Safari nightlies do too. Internet 
> Explorer
> and Firefox fail the testcase. Personally I would be in favor of changing the
> specification to be compatible with Opera 9 and Safari given that what they do
> is sensible.

Why can't this be left undefined? what does it matter to have
interopable rendering on invalid DOM changes?  Surely forcing code
changes on anyone is just a waste of implementation time here, not
updating the page when the DOM is changed to an invalid number is a
good optimisation?

IE for example simply rejects the update (the size remains at 2), that
seems like a sensible approach, as does normalizing it to 1.

I simply don't see the value in standardising the error behaviour here.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/5/06, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Sun, 5 Feb 2006, Lachlan Hunt wrote:
> Probably doesn't matter which group does it since it'd end up being me
> doing the work either way...

Well the review processes are slightly different :)

> I can certainly see myself speccing a getElementsBySelector() API as part
> of Selectors 2. But either way, the spec for gEBS is simple; it returns
> the same type as getElementsByTagName(), it is accessible from Document
> and Element nodes and selects a subset of the descendants of that node, it
> takes a single argument (a string representing a selector), its first
> version doesn't support namespaces, and it raises an exception SYNTAX_ERR
> if the string can't be successfully parsed by the UA.

As a general outline this is very good, ducking the tricky issue of
namespaces is sensible, and much I prefer this sort of proposal to a
specific className one.

Cheers,

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/5/06, James Graham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > On 2/5/06, James Graham <[EMAIL PROTECTED]> wrote:
> > DOM 3 XPath is of course only defined for XML, whilst it's no trouble
> > defining it for valid HTML, it's not currently, for this reason I
> > would prefer just having a CSSSelector method and not bothering with
> > an XPath one, defining XPath for HTML is a bit of a pain - indeed I'm
> > not completely confident it's possible on an invalid HTML document
> > until after the document has finished loading.
>
> In practice it works fine in Mozilla for HTML which, given it's DOM
> functionality, isn't so surprising since both XML and HTML end up
> constructing a DOM.

"in practice" isn't really good enough for a specification any more,
it was when HTML 4.01 or DOM 1 or DOM 2 or CSS 1 or CSS 2 came out, it
is no longer, and specifications are actually getting proper reviews
now.

I think it would be better to just leave XPath in HTML unspecified -
wish individuals and UA's luck if they want to try to use it on HTML,
but don't try and help them too much.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/5/06, James Graham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > So something with no implementation should be taken over something
> > with an existing implementation, that's pretty odd.
>
> Surely you can see that's a insane argument given the relative
> complexity of implementing the _entire_xbl_spec_ vs. implementing a
> single DOM method.

Of course, I wasn't actually making the argument.

> So the only reason to add a
> getElementByCSSSelector method is because we feel that either a) DOM3
> XPath is too hard to implement and getElementsByCSSSelector is much
> easier or b) because the added authoring simplicity provided by using
> widely understood CSS selectors is worth the substantial increase in
> complexity that providing two methods to solve the same problem will bring.

DOM 3 XPath is of course only defined for XML, whilst it's no trouble
defining it for valid HTML, it's not currently, for this reason I
would prefer just having a CSSSelector method and not bothering with
an XPath one, defining XPath for HTML is a bit of a pain - indeed I'm
not completely confident it's possible on an invalid HTML document
until after the document has finished loading.

> I do however know that arguing "we shouldn't implement feature x because
> more complex features y and z provide a superset of x's features" is
> wrong if a cost benefit analysis shows that x is better "value for
> complexity" than y or z.

Of course it should!  but remember also the cost of not doing x is
relevant, and the likelyhood of y or z being implemented anyway.  
There's little point in requiring feature x be implemented if feature
y and z are being implemented anyway, that's just bloat.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/4/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

> One issue with a Selector method though, how do we handle namespace
> prefixes?  Selectors states that the mechanism for declaring a namespace
> prefix is left up to the language implementing Selectors.  If we say the
> script uses the same prefixes declared in the markup using xmlns:foo="",
> then that ties the JS to the document and other documents that use those
> same prefixes.

I think that would be a bad idea, as I think you are, for the same
reason as the QNames in attribute context we've heard so many times
before from me.

>  If we say it uses those declared in CSS with @namespace,
> then that ties the script to the CSS.  Would we need another method
> called addNamespace(namespaceURI, prefix)?

Off the top of my head I would suggest a namespace handler object that
exists on the object, and if the stylesheet language of the document
is css it's pre-filled with the namespace's from css.  This allows us
to have simple use for the CSS case whilst still supporting the
flexibility to add namespaces later.  but that's very much off the top
of my head.

Cheers,

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/4/06, Brad Fults <[EMAIL PROTECTED]> wrote:
> I fully admit the possibility that this may be better accomplished
> with some other theoretical and/or vendor-specific technology, but you
> again missed the core point.

the core point is we're inventing something new to meet a use case,
you invent the best thing to meet the use case, you don't invent
things that allow you to write loads more script to fulfil the use
case.  Of course if there were lots of use cases then the general is
good.

The problem is people on this list are continually inventing methods,
without considering the use cases, hopefully by forcing people to
voice the use case and defend it against superior, already implemented
technologies like -moz-binding will mean that people will give the
information first so we are actually able to evaluate their proposals.

You cannot evaluate a proposal without knowing the use case.

> If they are useful, then getElementsByClassName() is
> also useful because it gives an author *more control* over the DOM for
> solving the *same types of tasks*.

That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.You don't continually add methods,
methods are complexity, they need writing, they need testing etc.  you
have to have a reason to add a method.

> The reasons why XBL is not currently an acceptable substitute are
> numerous, including its extremely limited implementation,

So something with no implementation should be taken over something
with an existing implementation, that's pretty odd.

> its separate
> and higher learning curve, and the fact that it doesn't hurt anyone to
> have two methods to accomplish similar tasks,

It absolutely does hurt to increase complexity of implementations,
specifications and tests!

> > I do not personally see the use case for a class specific operator,
> > either a CSS Selector method, that selects on any CSS selector, or
> > nothing seems appropriate.
>
> With all due respect, whether you personally see the use case for a
> specific method to be defined for use by all web authors is largely
> irrelevant.

Well everyone's opinions on the list are largely irrelevant, the WHAT
individual has sole discretion of what goes in.

> If other authors and designers do see use cases and have
> concrete examples of where this function would add a great deal of
> power and flexibility to their tool set, it is worth consideration and
> design.

But a CSSSelector method has more power, not less, and adds little in
implementation complexity surely?

> It is unfair to the rest of the contributors to this specification and
> web authors in general to hold up the design and/or implementation of
> a (generally-agreed) useful tool due to simple personal differences in
> taste or opinion.

I'm not holding up anything?  This is not a democracy.  If you want a
quality specification though, you engage in debates with people who
have opposite ideas.  People have shown enough use cases that indicate
the ability to select elements by a css selector is a useful function
- they've not made the case to me at all that a class name specific
one is useful though.

> Ian has already indicated that the specification of a method to
> collect DOM elements based on a CSS selector is best left to the CSS
> WG.

Then why isn't className?  or why don't we just wait for that, having
both cssselector and classname is needless verbosity.  Whilst
implementation of ClassName is trivial if you CSSSelector, increasing
the memory footprint of a DOM is not useful to anyone, and a severe
limitation on getting it on many devices.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/4/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> For example, if an author
> marked up dates in their document like this (due to the lack of a date
> element)
>
> 2006-02-03T01:30Z

A nice use case, and one well met by XBL including the currently
implemented -moz-binding, met much superiorly as that has quite
interesting effects for the screen reader user who is in the middle of
reading one of the dates...

Cheers,

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/4/06, Brad Fults <[EMAIL PROTECTED]> wrote:
> I can't believe that you're so insistent upon this extremely narrow
> set of use cases and that there aren't any other popular use cases for
> getElementsByClassName().

It's the only one that's ever been voiced without the extreme
prompting now generating some.The WHAT specifications (like the W3
specifications, indeed most specifications) are creating features, and
never voicing why they're necessary, the use cases are simply not made
- there probably are use cases for them, but they _must_ be voiced,
otherwise you simply cannot review them.

> The requirement for a loaded document is to be expected when one
> wishes to manipulate the constructed DOM from that document.

No such requirement exists in web-browsers today, why are you suddenly
inventing it?

> I want my designer to be able to specify an arbitrary set of elements
> in the markup for a web app that are to be "widgets". Now if the web
> app is sent out to a client that supports function X, I want to
> construct this X-widget around each of the elements in the set
> previously defined.

This use case is fulfilled by the -moz-binding and similar proposals,
it does this more successfully (as it does not lead to the
inconsistent UI problem)  I don't see the point in having both
className selectors and -moz-binding XBL approaches, but thanks for
the details.

> Now that we can get past "why" we're specifying such a function, I
> feel the need to reiterate the constraints on its specification,

but we can't know the constraints until we know why we're specifying it...

> 2. getElementsByClassName() must be *binding language* agnostic. That
> is, we cannot assume that it will only be used in JS.

I don't agree that it's necessary to do this, one of the historic
problems of the DOM in the ECMAScript context (and others) is that
individual language strenghts are not gained.  There is nothing
obviously wrong with having language specific API's.

> If getElementsByClassName() receives an array (synonymous with list),
> which all binding languages I am aware of are capable of supplying,

Do some binding languages not require the type of the parameter to be
specified as either an array or a string?

I do not personally see the use case for a class specific operator,
either a CSS Selector method, that selects on any CSS selector, or
nothing seems appropriate.

Cheers,

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Michel Fortin <[EMAIL PROTECTED]> wrote:
> Le 2006-02-03 à 09:30, Jim Ley a écrit :
> So to generalize the use case, when I want to attach an event to a
> child element or an element linked by any other mean to the element
> having that class, I can't use addEventListenerToClass.

So this shows that addEventListenerToCSSSelector is really what you
want so you can attach it to A's that are children of the class
doesn't it?

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> As an aside, I'd be interested in hearing about any JavaScript-less
> methods (that don't involve marking up every instance of the word; this
> doesn't work, as some are e.g. in href attributes.)

I was imaging your build environment making similar sort of changes to
your script and the two resulting copies existing.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > Yes, but they're all using it to attach events to every one of the
> > class, which is why you have to look at use cases, the reason they're
> > doing it is not because getElementsByClassName is missing, but because
> > addEventListenerToClass or -moz-binding etc. are missing.
>
> But why implement addEventListenerToClass() when you could implement
> getElementsByClassName(), which has a far more general utility? As soon
> as a single non-event-listener-related application comes along, you find
> you've implemented the wrong thing.

Er, no the use case people have is that they want everything that has
class X to respond to a particular event, if you model that with
getElementsByClassName then you cannot change a class on an element
and have it respond, without re-running the attachment, and manage the
fact you've already attached it to some classes etc.

It does not simplify the situation at all.  It can also only happen
once the element with the class is available, that fails the
consistency of UI axiom, since your element will respond differently
after the function has run.

> Here's a use case, then: the about:license document I just checked into
> the Mozilla codebase. When the page is called with the spelling
> "about:licence" instead of "about:license", I use
> getElementsByClassName() to search for elements with the class
> "correctme", and do a search and replace within them to correct the
> spelling. However, I can't correct it everywhere as I shouldn't be
> mutating legal documents. But I can do it in commentary, titles,
> contents and so on.

What an extremely odd use case, but it is at least a use case,
thankyou.  I'm not sure it's really one significant enough to warrant
implementing it given the large number of other methods of achieving
the same spelling correction.  Especially as the majority of them can
be done without requiring javascript at all.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> >  the document of course shows no use cases at all.
>
> Is there some doubt that the ability to tag an arbitrary set of elements
> and later easily get an array of those elements is a useful feature for
> web development?

I've yet to hear of an actual reason to do so, people keep saying it
seems useful...

> If you would like use cases, I present all of the web pages currently
> using a JS implementation of getElementsByClassName based on
> getElementsByTagName("*") and some manual class name inspection logic.

Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.

It's the classic mistake of looking at making the workarounds easier,
when you should be looking at making the underlying use easier.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > Rather than talk about technical details, can be talk about the actual
> > use cases please, working groups keep on creating things which need
> > implementing, testing etc. without once giving the use case.  This
> > thread is now 21 messages old and there's not one use case which is
> > fulfilled by a getElementsByClassName.  All the ones suggested are
> > fulfilled by the ability to attach events to a particular class name.
>
> I thought we were discussing it because it was in the spec? :-)

Firstly it has to justify its inclusion in the spec.  Until we know
what it's _for_ how can we possibly design it?  Or comment on any
individual design?

> I know nothing of this "attaching events to a class name" of which you
> speak. Can you give me a reference to a document or proposal describing it?

It's the one use case described in this mailing list,

See e.g. 
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/005434.html

 the document of course shows no use cases at all.

Jim.

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> This seems like a sensible change. Call it getElementsByClassNames()
> would make it obvious that if you supply multiple class names, you get
> only elements with all those names. And it would be a reasonably obvious
> reduction that if you just supply a single name, you would get all
> elements which had that one class name.

Rather than talk about technical details, can be talk about the actual
use cases please, working groups keep on creating things which need
implementing, testing etc. without once giving the use case.  This
thread is now 21 messages old and there's not one use case which is
fulfilled by a getElementsByClassName.  All the ones suggested are
fulfilled by the ability to attach events to a particular class name.

Jim.

Re: [whatwg] Web Forms 2 Test Suite

[Jim Ley]

On 1/23/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Quoting Jim Ley <[EMAIL PROTECTED]>:
> > It appears many of the tests require CSS 2, does this mean that Web
> > Forms 2.0 requires CSS2, I'd missed that, I am unable to test my
> > implementation because it is not a CSS user agent.
>
> There are quite a few tests that test the relationship of Web Forms 2 with the
> CSS3 Basic User Interface Module as mentioned in section 8.2 of the Web
> Forms 2
> specification. These test also rely on some CSS 2.1 features I assume, yes.

Well testing those is of course fine, as it's testing CSS 3 !

> Some other "visual UA orientated" tests might do the same. Given your
> comment I will try to make all forthcoming tests that not really require
> CSS not to use  it either and use some other mechanism to show
> that the test has passed. By,
> for example, using some scripting as already done in quite a few tests.

A combination of things would be good if possible.

Cheers,

Jim.

Re: [whatwg] Web Forms 2 Test Suite

[Jim Ley]

On 1/23/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> 
>
> Most of the tests are inside the "controls/" section. There need always need 
> to
> be more tests obviously. Currently it hosts a over two hundred test files if
> I'm not mistaken, but not everything is covered yet. In "elements/" some
> elements are missing and some controls need to be covered as well.
>
> Feedback, new tests and other things are appreciated.

It appears many of the tests require CSS 2, does this mean that Web
Forms 2.0 requires CSS2, I'd missed that, I am unable to test my
implementation because it is not a CSS user agent.

Otherwise good work, I'm glad to finally see the beginnings of a test suite.

Jim.

Re: [whatwg] Sandboxing scripts: call for a wider discussion

[Jim Ley]

On 1/23/06, Alexey Feldgendler <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Jan 2006 17:15:39 +0600, Lachlan Hunt
> <[EMAIL PROTECTED]> wrote:
>
> > http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011210/html.html#ID-75233634
>
> I'm surprised. document.write is defined but it's substantially different
>  from what the browsers implement. DOM 2 says that write() can be called
> only between calls to open() and close(), and that a call to open() clears
> the existing content of the document.

That's because the existence of a global object called document that
points to the current document doesn't exist in any standard.

> This is very different from the
> current practice of calling write() without open() to inject unparsed HTML
> into an already-parsed document.

Er, no, no UA supports this, it supports it in HTML documents _that
are being parsed_ but not ones that are already parsed where
document.write performs an implied document.open() so content is
cleared.

Jim.

Re: [whatwg] The element and "display: meta"

[Jim Ley]

On 1/22/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> However, I'm still not sure what problem is being solved here.

Me either, I know it gets boring me saying it, but one of the problems
with working groups of all denominations, is the focus on the
technical features rather than the use cases.

What I'm guessing the problem is

"I want to produce a web-application that exposes certain  features in
a way consistent with other web-applications and consistent with the
underlying window manager."

I don't think that's solvable with simple measures like this, nor am I
actually convinced of the utility in solving it, if you want to create
Web Applications that go-outside the document, then your own mozilla
container, or a Mac desktop widget thing, or a Opera widget thing, or
a Zeepe.com widget thing is the approach to go down.

Cheers,

Jim.

Re: [whatwg]

[Jim Ley]

On 1/19/06, Tyler Close <[EMAIL PROTECTED]> wrote:
> On 1/19/06, Jim Ley <[EMAIL PROTECTED]> wrote:
> > No, they'll just disable it, as it does them directly no benefit and
> > has a cost, so if you educate them enough to make a decision, they
> > will not decide to be tracked.
>
> Why hasn't this happened to the HTTP Referer header?

Because no-one's ever attempted to educate people enough to make a decision.

> I think an economic analysis of the scenario is a valid approach.
> Could you spell out your argument in more detail? For example, after
> I've submitted a search request to Google, what is the economic cost
> to me of letting Google know which result I selected? What is the
> economic benefit to me of providing this information to Google?

You're now discussing a very minor use case, the main use case is in
advert tracking, the economic case here is clear, accurate information
is required by the people paying for the ads to be shown and those
showing the adverts - if you're allowing an ad-service to show adverts
on your page, are you willing to accept that ad-service using a
disableable method of tracking what to pay you?

The use case of tracking what you click to leave a site is that it has
no direct benefit to the user whatsoever, they gain nothing at all,
and there's the slowness cost - indeed the site may be slower still if
they use redirect methods, but that's the sort of cost that would make
the tracking uneconomic as it will annoy users.

> I get more
> value in the future for revealing my search terms, in terms of better
> query results.

People don't make the same search more than once, google already knows
what the most popular search result on a particular term is and
without knowing what it was you were actually looking for (most search
terms don't express this very well) and what happened when you arrived
at the site they cannot know how useful the link truly was.

but mostly that's a minor use case compared to the main reason for
leaving site tracking, and that use case the ping proposals abjectly
fails to meet.

Jim.

Re: [whatwg] Definition of alt= attribute

[Jim Ley]

On 1/21/06, Matthew Raymond <[EMAIL PROTECTED]> wrote:
> Alexey Feldgendler wrote:
>   If an  element is being used in a "certainly presentational"
> way, should it not be done away with in favor of CSS?

CSS only allows for background images not for other presentational
images, to cover for this "feature" of CSS, presentational images that
are not background images are used in HTML.

Jim.

Re: [whatwg]

[Jim Ley]

On 1/19/06, Tyler Close <[EMAIL PROTECTED]> wrote:
> I think it would be fair to characterize current techniques for link
> click tracking as "opaque". In contrast, the proposed "ping" attribute
> explicitly declares in the HTML what is intended and how it will
> happen. Perhaps the right way to explain the "ping" attribute is as
> providing transparent, or explicit, feedback; shining a light on the
> dark corners of click tracking. If it is explained that the feature
> will make link click tracking explicit, controllable and more usable,
> I think the user base will react more positively.

No, they'll just disable it, as it does them directly no benefit and
has a cost, so if you educate them enough to make a decision, they
will not decide to be tracked.

Since the main use of tracking has a direct economic cost to many
parties the sites will then return to using the established successful
methods for tracking, no-one will gain and browsers would've wasted
lots of time that could've been spent on more productive features.

Jim.

Re: [whatwg] Definition of alt= attribute

[Jim Ley]

On 1/19/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Quoting Alexey Feldgendler <[EMAIL PROTECTED]>:
> > I wonder why alt is a required attribute for IMG in HTML while an
> > empty  value is allowed.
>
> Because an empty value means that there is no alternate text and no
> attribute at
> all means that alternate text is missing. (Which is clearly not what
> you want.)

I think Alexey's point is that in a correctly authored page no alt
attribute could perfectly reasonably mean the attribute is empty, this
is a good argument, but one that falls down in reality because so few
pages are correctly authored so those groups needing good ALT are left
at a disservice unless authors co-operate by specifically giving ALT
an empty value.

Jim.

Re: [whatwg] UA validation and the submit event

[Jim Ley]

On 1/18/06, Hallvord Reiar Michaelsen Steen <[EMAIL PROTECTED]> wrote:
> I'm not suggesting that we shouldn't fire onsubmit at all, only that
> perhaps it would be more backwards-compatible if onsubmit took place
> after the UA validation.

But it still doesn't fire if the useragent prevents validation?
 That would certainly be safer than as I read your previous proposal,
I'm not confident it wouldn't break some legacy pages.

> I'm not sure if making that impossible would be a big limitation.

Certainly not for future scripts, but the problem is the authors
who've never heard of Web Forms 2.0...

> > You should implement the behaviour only for documents identified as a Web
> > Forms 2.0 user agent.
>
> I think we've been there, discussed that and voted against using any
> xmlns or DOCTYPE tweaks to distinguish a document as a WF2 one.

Voted???

> The only thing I want to discuss in this thread, is: should firing
> the onsubmit event and UA validation happen in reversed order to
> ensure backwards compatibility with scripts that believe a form has
> been submitted when it hasn't due to a validation error?

Couple of points to note off the top of my head:

  WF2 aware scripts need to know that validation happened and failed.

  Legacy scripts need to know if a form was submitted - you can only
do this by not ever suggesting that it had been as far as I can see
which means not firing onsubmit event.

So I would certainly agree that firing onsubmit after form validation
is the only way to ensure backwards compatibility, it may be that we
need an onaftervalidation type thing which fires after validation is
complete so WF2 aware UA's can do the same disabling/screen tidy up
that we want to do.

Note I don't think this will still be compatible with all legacy
clients, there's lots of scripts of the type:



where non form controls are used for the submission, so I don't think
either of the proposals are going to be perfect, which is why I think
it's important to ensure that user agent validation can only occur
with the explicit awareness of the author - not as a byproduct of
including another attribute.

Cheers,

Jim.

Re: [whatwg] UA validation and the submit event

[Jim Ley]

On 1/17/06, Hallvord Reiar Michaelsen Steen <[EMAIL PROTECTED]> wrote:
> Kayak.com is in trouble because they've set a maxlength that is
> smaller than some of the data the script sets input value to. (I'm
> sending them some feedback about that). However, the site shows an
> interesting problem: the UA (testing in Opera 9) does not submit the
> form because of the validation problem, but the onsubmit event has
> been called, meaning the site has disabled its submit button. Hence,
> the user has no way to fix the data and resubmit (even if she
> actually understands what the error is).
>
> Should we really fire onsubmit if the UA prevents submitting the
> form? Button-disabling-on-submit scripting isn't exactly rare..

I think you have to fire onsubmit, there are also lots of other things
people do onsubmit - copying information into hidden fields, calling
tracking scripts etc.  It's really an issue with the user agent.

The problem here is actually a problem of backwards compatibility,
current user agents do not stop submission when maxlength is too long.
 This means valid content, The HTML 4.01 doesn't say that having a
value longer than maxlength is an error, won't work in user agents.

You should implement the behaviour only for documents identified as a
Web Forms 2.0 user agent.

Jim.

Re: [whatwg] getElementsByCSSSelector

[Jim Ley]

On 1/14/06, liorean <[EMAIL PROTECTED]> wrote:
> On 14/01/06, Jim Ley <[EMAIL PROTECTED]> wrote:
> > Could you explain some use cases?
>
> For the very same reason you might want DOM to provide an XPATH
> engine, TreeWalkers or NodeIterators - To get efficient host-native
> filtering of the node tree. In this case, filtering based on a scheme
> used in related technologies. Preferably returning a DOMCollection
> instead of a static array or matches.

The use case for Regular Expressions are clear - I want to detect if a
string is something that is probably a date in a particular format
etc.  The equivalent for a DOM is not clear - if your argument is
purely efficiency - which could be a good one certainly - then you
still need use cases that justify the underlying technique - I want a
nodelist of all things in a document which match a particular CSS
class is not an obvious one to me - every use case I can see for it is
better to simply change the CSS class itself.

Jim.

Re: [whatwg] getElementsByCSSSelector

[Jim Ley]

On 1/14/06, Julien Couvreur <[EMAIL PROTECTED]> wrote:

[use cases for CSS selectors]
> One of the main uses is to bind behaviors to elements. This allows for
> a clean markup with a well separated logic.

Then it fails miserably at the job,  HTML documents render
progressively, behaviour also needs to render progressively,
getElementsByCSSSelector fails at this.

There could indeed be useful methods for achieving this functionality
sort of thing - for example something along the line of events bound
at the css selector level, something like -
cssSelectorAddEventListener(".chicken td","DOMActivate", ...) maybe?
but your proposed DOM method fails to meet your described use case -
do you have any others, some that actually succeed, rather than being
a half way measure based on current practices that are stuck due to
the limited nature.

Jim.

Re: [whatwg] getElementsByCSSSelector

[Jim Ley]

On 1/14/06, Karoly Negyesi <[EMAIL PROTECTED]> wrote:
> A getElementsByCSSSelector IMO would be great and introduces minimal plus
> burden on browsers -- they have CSS selector code anyways.
>
> It's very unfriendly that I can do magic with CSS2/3 selectors and then I
> need to translate them myself if I want to change them on-the-fly.

Why would you want to change the content of all elements that matched
a particular selector?

Could you explain some use cases?

Jim.

Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Jim Ley]

On 1/1/06, Sander Tekelenburg <[EMAIL PROTECTED]> wrote:

I'm a 100% with Ian here, LINK is dead.

> It could offer "shortcuts" (key combo's) to standard LINKs like
> next, previous, help, search, home. Etc.

next/previous - most pages on the internet don't have a meaningful
next/previous state, and those that do are generally only navigated
via forms.  And the few places you do seem them, people don't have a
problem navigating it and only want to do so after consuming the page
(e.g. a multipage article)

help - how many sites does this apply to?

so search - marginally relevant and home are the only ones that are
really used regularly - your Etc. is a pretty big etc. as there really
aren't any more.

> (As to us "failing": 5 years ago only lynx and iCab offered LINK support.

And IE of course, okay through an extension, but still, that's the
same as with other current UA's you're counting.

LINK's have certainly failed, there is simply not enough consistency
in webpages to meaningfully derive labels that have meanings which
cross these types - take a few popular pages, say a mapping service, a
wikipedia article, a book on a bookshop page, an auction page, a
personal photo page, and create the LINKs here that would provide the
consistency to make it useful to users.

Jim.

Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Jim Ley]

On 12/31/05, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Dec 2005, Alexey Feldgendler wrote:
> > >
> > > It may just be me, but I perceive a great deal of difference between
> > > "IE supports CSS poorly" and "IE doesn't support CSS at all", only the
> > > latter of which seems relevant in the context of the `link` element.
> >
> > Here is a practical question: does IE show ed URIs in its Links panel?
>
> It doesn't have a links panel.

If we're saying that FireFox has a links panel because of a plugin,
then IE has shown ed URIs since IE4.

Jim.

Re: [whatwg] [WF2] form submission protocols and methods

[Jim Ley]

On 12/20/05, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>> Um, they shouldn't be able to. Or at least, in many UAs they can't.
>
> Do you know of UAs that will prevent a file: URL document from
> loading another file: URL in a frame or iframe? Or apply any
> restrictions to scripting access to the resulting document. I don't
> know of any that will.

Well other than Internet Explorer 6 on XP service pack 2 of course? 
Although there are of course still ways of doing it.

> I don't think reading /dev/mouse will specifically do anything bad,
> but I see your point. For file: in file: inclusion I think it would
> be wise to exclude certain system paths such as /dev and /etc. I
> think this may be done already.

This shouldn't be specified in the specifcation, what is safe to be
included can only be known to the user agent as it's wholly specific
to the platform and configuration of the platform.

Jim.

Re: [whatwg] XMLHttpRequest.status on connection timeout

[Jim Ley]

On 11/30/05, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> What should XMLHttpRequest.status return on connection timeout?  Ian and I 
> were
> talking about this, and it seems like "502" is a good response code here...
>
> See https://bugzilla.mozilla.org/show_bug.cgi?id=304980

I understood the aim was to mimic IE's implementation? Which will
return a 5 digit code in the 12xxx range from WinInet for errors not
returned by a server)

Of the 5xx 504 is more justifiable than 502, as then you can pretend
the browser is simply a proxy which has timed out,  502 which
specifically mentions an invalid response doesn't sound a good idea.

I believe Safari now has a 1 year timeout, so that could be an
interesting test to run on a release build :-)

Jim.

Re: [whatwg] [html5] html:style parsing

[Jim Ley]

On 10/30/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
>  
>
> (Mozilla seems to treat elements and comments differently as shown in 001, 
> 002,
> 003 and 004. Both testcases all show green in Opera and Mozilla.)

Is this not a bug? I can't see anywhere in any XHTML specification
that states that html:style children of html:style elements should be
treated as if they were stylesheets.

> That should probably be reflected in the description of the html:style element
> (that elements with known semantics are parsed).

"reflected in the description"  surely the bugs in the UA's should be
fixed, there's no-one relying on such documents, so it's not something
that needs codifying to make the web more consistent.

Cheers,

Jim.

Re: [whatwg]

[Jim Ley]

On 10/22/05, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Oct 2005, S. Mike Dierken wrote:
> > Oh, that really shouldn't be done via POST. Clicking a link should be
> > safe and sending a POST as a side-effect is not safe.
>
> GET means that you can do it again without affecting anything. In the case
> of tracking, you can't -- the very act of contacting that tracking URI can
> cost someone money. Hence POST. (This is another advantage of ping over
> redirects, come to think of it.)

No!, because just because someone has done it again doesn't mean that
no money should change hands.  If I provide a site that ends up
linking to X, and people fail to remember where X is but instead use
the adverts on my site, I'm still providing the service.

For me this is simply not going to work, adaware, norton internet
privacy, and similar etc. will soon reconfigure the browser to stop
the ping's, as it's irrelevant to the user experience users won't
care, however major search engines which derive significant income
from tracking will have to revert to detection methods

The previously proposed "is ping supported" script is definately not
sufficient for even coping with todays browsers let alone future ones
which disable the tracking.

Redirects work because the user cannot get the information they're
paying for without being tracked (except of course in the case of many
google adverts which leave the destination url in the tracking uri
which means google loses the money for those clicks.)  As you're now
making it trivial for users to get their information for free I can't
see what possible advantage this is to anyone trying to track
reliably.

As I and the site know this is going to under account for my clicks, I
fail to see how a 3rd party ad broker using this could survive any
sort of audit of their service, they would simply not be providing an
accurate service.

For unreliable tracking, it's more relevant certainly, but the
unreliable tracking use case isn't a great one, and I certainly don't
see the point of new stuff.

Jim.

Re: [whatwg] comments on Web Forms 2.0

[Jim Ley]

On 10/13/05, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Oct 2005, Josh Aas wrote:
> > - Section 1.1: "browsers prevalent in 2004" - could be more specific
> > given that the number of decently conforming HTML 4 and DOM
> > implementations can probably be counted on one hand (Gecko, KHTML, IE,
> > Opera). This could better set the bar in terms of what is considered to
> > be an acceptable implementation.
>
> For political reasons it has been considered wiser not to actually mention
> specific UAs. (In reality, user agents like Lynx and others were also
> taken into account, actually.)

Very wise, especially as the IceBrowser component was certainly as
capable as the above listed, and there's at least one other mobile
browser that has a reasonable DOM, which pushes us over the one hand. 
 Listing things is always dangerous as if you miss one, it looks like
it was deliberate - definately a bad idea for a vendor sponsored spec.

Jim.