Re: [whatwg] scripts that remove focus from links during document navigation
On 20/09/06, Hallvord R M Steen [EMAIL PROTECTED] wrote: a href= onfocus=this.blur() 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.
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
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
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?
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?
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
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
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
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
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
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
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
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
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
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] diffed versions (CVS)
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 select
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 select
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. Jim.
Re: [whatwg] [wf2] changing the size DOM attribute of select
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] getElementsByClassName()
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()
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()
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()
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()
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) span class=date2006-02-03T01:30Z/date 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()
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] getElementsByClassName()
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()
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] Sandboxing scripts: call for a wider discussion
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] a href= ping=
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
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] a href= ping=
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] UA validation and the submit event
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
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] getElementsByCSSSelector
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
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] [WF2] form submission protocols and methods
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
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] some feedback on Web Apps 1.0 client-side storage
On 9/30/05, Robert O'Callahan [EMAIL PROTECTED] wrote: On 01/10/05, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 9 Sep 2005, Robert O'Callahan wrote: Then the UA might have to terminate any running script(s) (perhaps after warning the user and giving the user an option to cancel the emptying). Do we really want to require this? I agree that a user agent may wish to do this, but it seems that the interaction of the user deleting data and running scripts accessing that data would be something that could be safely left undefined, since it doesn't directly impact interoperability. I agree, I see no reason to define it, users (and by extension their tools) should be free to delete any data on their machine at any time they want. It is also the sort of thing that it would be trivial for the user to do (using any of the many methods of executing script e.g. userJS greasemonkey etc.) I think some sort of guarantee that data can't just disappear while a script is running would be very helpful to developers, and of course they'd be more able to rely on it if it was in the spec. Authors don't currently have this safety - most of them just ignore the problem, and I don't see any reason for it - what's the worst that can happen - good authors should be coping with just about any situation, that's the environment the script is executing in. Jim.
Re: [whatwg] getElementsByClassName()
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote: Aankhen wrote: I suggest #2, which implies consistently treating the first argument passed to the function as a single class name to match (this means foo bar would always return no elements, No, as already demonstrated, #2 does return matches in some cases. Surely that's just an implementation bug? rather than indicative of any underlying problem in the spec. The ElementClassName file : className = className.replace(/^\s*([^\s]*)\s*$/, $1) doesn't enforce the classnames have no spaces in them and results it in continuing to test the className attributes with a regexp containing the space. a quick untested fix would I think be: className = className.match(/^\s*(\S+)\s*$/) ? className.replace(/^\s*(\S+)\s*$/,$1) : ; (also using \S rather than [^\s], but that's purely style of course) Special-casing foo bar and other values seems to be adding complexity without much return. It's not about special casing, it's about defining error recovery consistently between implementations. As it's currently defined, (foo bar is, I believe, erroneous since each parameter represents a single class name. I think it is defined in the spec, it's erroneous, and your implementation is just broken as above, I'd quite like it to be defined as 3, mainly because a DOM binding with optional parameters isn't language independant, and if it's a ECMAScript tied DOM, then the DOM needs to be a lot more ECMAScript like. Jim.
Re: [whatwg] [WA1] The a element could be empty
On 9/3/05, Matthew Raymond [EMAIL PROTECTED] wrote: Jim Ley wrote: Not particularly wanting to support the OP's issue - I don't see a problem with the change to the content model of a to require content, it's a good thing. However styling a link to print away is not a good idea, as it means those without css get a link which does nothing, Nothing in a print out does anything. The relevance to the button doing nothing, is the button on the page that if script is enabled and appropriate vendor API's are available will print the document, so the the OP only adds the link once he knows script and a window.print method are available, not after printing. How many user agents support Javascript but not CSS1? Does Lynx or some other text-mode browser support Javascript? I'll have to look into that... Loads, IE, Mozilla Family, Opera and Safari perhaps being the commonest - ie CSS can be disabled in all of them distinct from disabling script. Makes sense. Personally, I'm wondering why you want to print from a link at all unless you want to perform a special print operation. Oh absolutely, it's silly (without having things like ScriptX to provide real printing support in restricted environments) but you can't hide scripted things via CSS, CSS and Script can be disabled seperately in all modern browsers. Cheers, Jim.
Re: [whatwg] [WA1] The a element could be empty
On 9/2/05, Matthew Raymond [EMAIL PROTECTED] wrote: 1) Why wouldn't you want the content in the element to be inserted by Javascript when the page loads when you can just include the content in markup and hide it using CSS? Not particularly wanting to support the OP's issue - I don't see a problem with the change to the content model of a to require content, it's a good thing. However styling a link to print away is not a good idea, as it means those without css get a link which does nothing, of course it's still possible with the method in the OP's post that the user gets a nothing link, but that doesn't mean the link existing in the source is a good idea. 3) How does your original example even prevent the content from being viewed when printing? I don't think that's the purpose, I think the purpose is to ensure there's not content in the page which is purely behavioural and does nothing when script is not available. 4) What prevents you from inserting the entire a element into a span? That is of course a very, very good question. The bottom line is that you need a much better use case. Absolutely! Jim.
Re: [whatwg] Semantics in WYSIWYG
On 8/30/05, Maniac [EMAIL PROTECTED] wrote: Jim Ley wrote: WYSIWYG editing has to produce tag-soup, it's free of semantics, as the wysiwyg cannot know the semantics intended by the user, for that reason the only way is to limit the elements to those with only strong semantics - links, images etc. That won't work. People use blockquote for indentation as we know. with contentEditable as implemented in IE and mozilla currently (with a paste rich text block in place), it works as the only way users can enter mark-up is with their limited controls provided by the page author. I also think that WYSIWYG semantics is essentially very hard anyway... Absolutely, which is why you constrain the problem to something manageable. Jim.
Re: [whatwg] What exactly is contentEditable for?
On 8/30/05, Matthew Raymond [EMAIL PROTECTED] wrote: You're talking about defining behavior for a semantic element. You're essentially dictating parts of the implementation of |contenteditable| to user agent vendors. Not at all, I'm saying the current implementation in IE is appropriate for the use case, and moving away from IE's implementation will bring new potential use cases into what's possible, but at the expense of current use cases. I've not actually seen many people wanting full on editing of entire web-pages in a web-page, most of the use cases involve editing of parts of webpages in constrained fashion. especially if IE doesn't have those limitations. I'm not asking for any changes to IE's implementation of contentEditable, whilst not being good, it does meet the use case I'm raising here. I'm arguing against changing it to try and meet other use cases - I agree entirely with your other post with your 3 suggestions, leave contentEditable as is but well defined, add other elements. (Wouldn't they have to have hit a blockquote button on their toolbar to get that?) Who knows what UA's might do, it was just an example, I'm sure you can see the general issue. It might be nice, but I can't see how a user agent could really achieve such a thing, what's it going to do change its edit bar for every user, that would lose any consistency that would be gained by providing it in browser. Oh, I think I get it. You don't necessarily want there to be toolbars and the like, No, I want contentEditable left as is, because not all the use cases and delivered products of contentEditable are applicable to full spectrum HTML authoring, they're limited to elements, no CSS, they're limited in what elements they use etc. A UA toolbar in a textarea accept=text/html would be a great idea. Is a simple, straight-forward rich editing control too much to ask for? Absolutely not, but it's not the same thing as contentEditable, it has different use cases, that's all I'm saying, we need both, not just one. Cheers, Jim.
Re: [whatwg] What exactly is contentEditable for?
On 8/29/05, Hallvord Reiar Michaelsen Steen [EMAIL PROTECTED] wrote: On 24 Aug 2005 at 12:16, Ian Hickson wrote: contentEditable needs scripting anyway, to offer things like insert em element here, etc. Why must contentEditable depend on scripting? What if we make sure the wording of the spec allows non-scripting implementations? Please, no, a lot the use cases for contentEditable are not full wysiwyg editing, a lot of the ones I create allow only a minimal subset of editing, and they do this by scripting, if you can only strong/make link/italic/colour/insert image, then you get a simple editor that allows for easy editing, but doesn't run into much tag-soup that needs elaborate cleaning up. Whilst I agree the concept of contentEditable is not good, I don't think it should be solved by trying to modify the existing behaviour the accept=text/html is a much better way of meeting your use case. My question is whether we could make contentEditable more useful for HTML/CMS authors by removing scripting requirements. I would be extremely unhappy, and would need to find ways of blocking browsers that implemented contentEditable in this manner from providing the functionality, that's not a good thing, but the risk of letting any user/browsers attempts at html into the CMS would be worse. So whilst I agree with the need, please seperate the browser provided from the script provided interfaces. Cheers, Jim.
Re: [whatwg] removing attributes
On 8/5/05, Olav Junker Kjær [EMAIL PROTECTED] wrote: Is it possible to remove a constraint like maxLength (on input elements) through script, eg. by setting it to null? By default a field does not have any maxlength constraint, so it would seem natural that if you set a constraint through script, it could be removed again. Wouldn't just calling removeAttribute of the HTML DOM do this? Jim.
Re: [whatwg] [html5] onbeforeprint/onafterprint (was window.print() undefined)
On 7/20/05, Matthew Raymond [EMAIL PROTECTED] wrote: Jim Ley wrote: This is another of the use cases I've used enhanced printing for - I actually generally used ScriptX http://www.meadroid.com/scriptx/ rather than simply the IE methods, but the events are all that's needed. Not paying for printing images, but swapping out images with higher quality images suitable for print. Once again, I don't understand why you can't simply provide the user with a button on the web page that either calls up a printable version or clones the document so that the clone can be used for printing. The main reason is that my users have always said they want to use their regularly printing mechanisms, not some link that opens a new page, and then lets them do it, it's simply much too slow for any of the users. There's also signficant problems - the server implementation for your above is extremely complicated and slow - any user modifications need to be serialised into a suitable format for supplying to the server, then it needs to develop the equivalent view in the static format suitable for printing, then it needs to return it - increasing server load, implementation complexity and bandwidth usage. As you note the DOM clone is not a method that exists - because of that, lets forget it, web-applications need to work in IE, we can't implement that in IE. a separate printable version page is sufficient. Such a solution has been regularly rejected in various projects, I don't think it's likely to happen in the future either, much more likely that IE only will continue to be required for the applications, or at least the high-quality printing components of them. ActiveX is commonly used in intranet applications. Not at all, there's lots over the public web, not to a general public audience of course, and web technology is very important in the non-web world, it's also the area that IE still utterly dominates. Now you've completely lost me, use-case-wise. On an intranet, why is a printable version of the document not an acceptable workaround? In a nutshell - Because you can't print it by pressing ctrl-p, and all the reasons above. It really doesn't matter though, because manipulating and printing a copy of the document is more effective anyways without disabling or changing part of the browser functionality. What ways? Here's a question for you to chew on: What happens if you want to print and the webmaster screwed up something in the onbeforeprint or onafterprint event? Will it effectively disable printing? Of course not, you'd just disable script and print... What if it's an AJAX application and the UI of the app is hidden for printing but never restored? Just the same as happens with things like gmail when the UI disappears ot locks up or whatever, the user presses refresh and starts again. Of course in the real world we also have QA procedures with testers making sure this sort of stuff doesn't happen, javascript breaks sites in millions of ways every day, more events don't make it more likely - they often make it less, as viewer hacks are needed to hit the required functionality. In any case, protecting stupid developers is not a good approach to spec authoring, all you do is harm your intelligent developers, and your users who lose functionality they want. Jim.
Re: [whatwg] [html5] onbeforeprint/onafterprint (was window.print() undefined)
On 7/19/05, J. Graham [EMAIL PROTECTED] wrote: On Tue, 19 Jul 2005, Jim Ley wrote: Someone will probably suggest CSS background-images as a suitable for this aswell, yet again ignoring the fact that CSS is _optional_, and content-images must not be in background images as they simply won't be seen without CSS or if background images are disabled. Er.. script is (in practice) at least as optional as CSS since more people actually disable script than use alternate stylesheets. Yes and no, we can only make these changes to the content with script so a script print solution is acceptable, for example in the above example the static non-scripted document would not have any of this media specific content in, it would only be added with script when appropriate, that way the media specific nature can be relied upon - the script is unobtrusive. CSS however is optional at the fine grained level. Jim.
Re: [whatwg] [html5] window.print() undefined
On 7/18/05, Ian Hickson [EMAIL PROTECTED] wrote: Why would you suspend a timer? (And why would the UA not suspend the timers itself?) You're saying that when a user print's an HTML5 user agent MUST stop all setTimeout counters, I don't see that in the spec, nor why it would be an expectation of a scripter. The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. Of course for showing temporarily hidden stuff with script, as has been mentioned, there's no problem doing it with CSS. Jim.
Re: [whatwg] [html5] window.print() undefined
On 7/19/05, Matthew Raymond [EMAIL PROTECTED] wrote: Jim Ley wrote: You're saying that when a user print's an HTML5 user agent MUST stop all setTimeout counters, I don't see that in the spec, nor why it would be an expectation of a scripter. So wait, we need to add new events because user agent vendors may be too stupid to solve print-related problems on their own? I'd rather not have events just to fix random user agent problems. As a scripter, I do not have an expectation that print will cause any effects on my scripts - Ian just said that it should have something that is the opposite of my expectation, as this is not defined, it needs to be defined - there are no user agent problems here. The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. What about the browsers that don't support Javascript, or have it turned off? They don't get anything at all, this isn't necessarily a problem - having content there which is visible on screen but not understandable is a problem, a requirement from a previous project was simply date of printing, this was required by the process, and the normal footers of the browser were suppressed. Another common one is adding links explicitly in the page - to do this with CSS requires CSS3 features, or for external links to be in a different class, and of course neither are available in the most important Web Application platform. Jim.
Re: [whatwg] Input type=date UI discussion
On 7/12/05, Dean Edwards [EMAIL PROTECTED] wrote: Jim Ley wrote: On 7/12/05, Dean Edwards [EMAIL PROTECTED] wrote: Well the customisation is just colours and chrome style. We'll attempt to guess the chrome style and replicate it. What I really mean is that we are copying the windows controls in terms of layout and the way they respond to keyboard/mouse events. There is no consistent response to keyboard and mouse events in windows, it's customisable. Please do not make the mistake that Mozilla made for the first 2 years of its life where its menus were unusable on windows if they'd changed the mouse configuration. Windows window manager customisation is not just look. You should either use the windows common controls, or you should have something that cannot be confused for the normal controls. Yeah. We are copying the windows common controls. As I say, please use them, or doing something different, copying something and getting it only 90% right (which is all that is practical as if you're doing this with zero install, that's all you have access to) then it's worse than being completely different. I said anything *in* the popup window. Yes, I understand that, I fail to see why a popup month view should not be usable by the assistive technologies, and more importantly how will you know what assistive technologies are being used? I'll say again AIUI, certain input modes and screen reading type things require a window to have focus to work. This is just my understanding, but I'm reasonably confident of it. The WF2 controls for IE will all be operable by keyboard. Think of a select box. The individual options are not focusable but they are navigable. The control has focus, just like in windows, the common date control gains focus. So Enter in a text box should submit a form, the same as if it was an input type=text? Is this in the spec? What are you asking? A text box should behave like a text box? It's not a text box, it's an input type=datetime (say), I'm asking is if that should act the same as a text box w.r.t. to enter submitting the form? Jim.
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
On 7/8/05, Hallvord Reiar Michaelsen Steen [EMAIL PROTECTED] wrote: This may imply that a client with a cached document should return a status 200 when the requested document matches one in the cache (whether or not the UA has checked with the server if the resource is current). I wouldn't be against this, if the resource is cacheable, then I'm happy that what comes back could be a 200 or a 304, all my implementations, and indeed any situation I can imagine where knowing a 304 on the client is for resources that are must-revalidate, if it's just naturally cacheable, I'm not sure the fact it's been checked for freshness is relevant. Consider a cache which updates itself every 20 minutes for a resource (without any request from the user agent), first time it gets a 200, then each of the next requests it gets a 304, when the user agent then makes a request to it, it's going to return the resource with 200, that's reasonable. So yes, I would be happy with the above interpretation, as long as a specific request from the script, results in that value being what's actually returned. I'm happy that cache itself operates seperately and simple freshness checks for a resource could stay as a 200 certainly. The arguments make sense. Cheers, Jim.
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
On 7/3/05, Hallvord Reiar Michaelsen Steen [EMAIL PROTECTED] wrote: On 3 Jul 2005 at 21:30, Jim Ley wrote: It's trivial to work around That is obvious. However, *will* people work around it, or will the browser that is better at caching documents be at a disadvantage because web apps will mysteriously appear broken to the end user..? XMLHTTP in IE is fully wired into the cache, and works appropriately, I can't see how the behaviour will differ in different caching scenarios in any case. IE also returns the exact status code recieved from the server. I don't think IE ever sends a conditional request for a document requested via XMLHttpRequest (I don't know every corner of the HTTP caching spec though). It does if the cache is appropriately configured. I think faking 200 would be in the interest of smaller browsers I don't see how hobbling smaller browsers helps them in any way. I also certianly don't see the point in writing a specification just for smaller browsers, but we've discussed that before. and make life simpler for JS authors under most conditions (I don't see much of a use case for wanting to know about the 304 response..) I've deployed a number of systems that rely on getting a 304 response to the xmlhttp request object - Generally the client has been polling a server for the state of a remote thing (the example most recently in my mind was the temp of a freezer) and if it's not changed since the last response, then I quite rightly send a 304, and test for it on the client, it was an embedded IE solution, and it worked fine in IE. Cheers, Jim.
Re: [whatwg] Using X3D in XHTML documents
On 6/21/05, Matthew Raymond [EMAIL PROTECTED] wrote: Matthew Raymond wrote: Now that I think about it, wouldn't the following be valid also?... | ?xml version=1.0 encoding=UTF-8? | !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN | http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; | X3D xmlns=http://www.web3d.org/specifications/x3d-3.0.xsd; Of course not, there is no X3D element in the above dtd. Jim.
Re: [whatwg] Web Apps 1.0: On-line help
On 5/8/05, Ian Hickson [EMAIL PROTECTED] wrote: On Sun, 8 May 2005, Ben Meadowcroft wrote: There are two types of help that I think are appropriate for web applications, full page help and element sensitive help. The problem with both is discoverability. Unless we can solve that, there is not much point having anything in the spec. For the context sensitive one we use CSS with a cursor:help that's the way we usually implement it from a visible perspective, I'm not sure if there's particular value in defining an attribute to take the help contents though, especially as this would mean it couldn't then have mark-up, which most of the context help systems I've done do use. adding in a link rel of help would seem a pretty low rent thing to define, how that may be exposed in a UI though I'm less clear, I don't like the idea of adding it to the browsers regular help chrome - there needs to be a distinction between browser and web-application. Jim.
Re: [whatwg] Web Applications and 3D
On 5/4/05, Matthew Raymond [EMAIL PROTECTED] wrote:
Jim Ley wrote:
Plug-ins are by their very nature optional. Why would we want to
move functionality into object elements, which are by definition
external objects like plug-ins?
OBJECT is not by definition a plug-in, and Opera/Mozilla/Safari/IE all
currently use native renderers to render OBJECT elements, there is no
reason why this should not continue.
How so? A 3d context would undoubtedly have functions for loading
complete textures and models from files.
Creating a 3D markup language is somewhat outside the purview of this
working group
Even if you assume the files
are huge and take an enormous amount of time to load, how is using a
plug-in that much better for the user experience?
I've never made any comments about plug-ins, OBJECT does not imply
plugin. The problem though is the very nature of creating javascript
API's to create scenes, rather than a 3D rendering language, if you
choose a 3D declaration language then the canvas API approach is not
appropriate either and a simple img src=something.what3D (or maybe
object) is the appropriate method of creating a scene.
canvas3d id=chicken/canvas3d
script type=text/ecmascript
var context=document.getElementById('chicken').get3ddrawingcontext();
context.loadExternalModel('something.what3D');
/script
Is simply bad, there's no rationale for all that extra indirection,
can I also remind you once again that the WHAT-WG individual has
stated:
Creating a 3D markup language is somewhat outside the purview of this
working group, though.
URL:
http://www.mail-archive.com/whatwg-whatwg.org@lists.whatwg.org/msg00726.html
your explanation of loading these external files, would require you to
create just such a markup language. This is the problem I have,
without external files of any sort, then a 3D api is pretty useless,
the fact it's been trivial in IE since 1997, yet hasn't been used, I
think makes that clear.
If by declarative you mean like X3D, then WHATWG clearly shouldn't
add such markup to HTML because it would duplicate the work of another
group unnecessarily.
Just like it's not necessary to embed jpeg's inside HTML documents to
get images in them, it's not necessary to embed 3D markup inside HTML
documents to get 3D images.
If I'm reading this right, you're saying that no one uses
DirectAnimation, and perhaps 3D in general, so why introduce a
potentially competing standard when there's no real demand for the
original?
I'm asking for you to justify your use cases, for example implement a
mock one in some pseudo code, you will see very rapidly that for any
of them to work they require externally defined 3D models, defining a
3D model language is somewhat outside the purview of this working
group. If you discover that you don't, then I will gladly concede
that your use-cases are practical.
As to the DirectAnimation, one of the fundamental principles of the
WHAT-WG is features should be implementable using behaviors,
scripting, and style sheets in IE6 today the only way to do that with
3D is to use a DirectAnimation layer, because of that, it makes
complete sense to just take the DirectAnimation API as a whole.
Jim.
Re: [whatwg] Web Applications and 3D
On 4/29/05, Matthew Raymond [EMAIL PROTECTED] wrote: Jim Ley wrote: Please do not re-invent the wheel, but standardise this (or a subset) functionality. The supposed motivation of WHAT-WG is compatibility with IE6, VML and DirectAnimation provide 2D and 3D drawing contexts that are compatibile with Internet Explorer, use them, or start coming up with some reasons why not to. The examples I've seen with regard to DirectAnimation are done through an object and use an ActiveX control, so standardizing such an interface isn't appropriate. Could you explain why? ActiveX is just the mechanism windows uses for componentisation - WHAT-WG is already standardising things implemented as ActiveX in IE. If you're saying that the creation mechanism for a 3D canvas is wrong - there's something wrong with using OBJECT, and we need to use CANVAS3D instead, then perhaps you might have a point, I'd like to hear a lot more motivation for inventing new elements for this, given the problems with new elements highlighted so often by Ian and others. However the creation is one minor part of the 3D API, and it's the API I was talking about. We may want to be able to implement the 3d context for canvas on top of DirectAnimation. Could you describe why this might be a motivation, what do you see as so lacking in the current implementation that it's not takeable as a whole? As always, I'm still waiting to hear the use cases for both 2D and 3D javascript drawing - Quake like games which is the only example I've heard so far, may be a use case, but it's not yet been explained why an HTML document is appropriate for such a game. I've already suggested the use of 3D for previewing a custom ordered product such as a motorcycle. All drawn in client-side javascript? - remember the use cases I'm looking for are not use cases for 3D, but for use cases for a 3D canvas in a webpage, that has no state, and relies wholly on all the information being drawn by javascript onload or later? I do not accept that the above is a practical use case. Perhaps you want to see a 3D representation of the hotel room you plan to book. Same for real estate. If you're ordering a ticket from a concert, wouldn't it be nice to see what the stage will look like from your seat? Need I go on? Yes, because none of these are being addressed by a 3d drawable canvas and a javascript API, the simple creation of any of these is not appropriate to a programming language, they are all declaritive, and the WHAT-WG individual has made it clear that a declaritive 3D mechanism is not on the agenda. If that is all that we get, then none of those use cases will be fulfilled. So I'm still searching for what use cases a javascript API to a 3D canvas provides, it's been possible in IE since 1997, I've done lots with it in that time, yet I've never come across a real wbe situation that has used it - I used it once to write some very quick pages that were 3D to be used on some notebooks at a trade show, back when notebooks having 3D graphics cards was a selling point. Jim.
Re: [whatwg] Canvas element - Keep It Simple
On 4/25/05, Brad Neuberg [EMAIL PROTECTED] wrote: If successful shipped implementations is what matters, then there's lots of successful IE extensions that do the same as canvas and other elements which it would be much more sensible to go with. I'm not against that; I thought one of the ideas behind the WHAT working group is to take already working defacto standards and simply specify them and implement them in other browsers, such as innerHTML and XmlHttpRequest. I'd much rather choose an already existing, if not perfect, canvas or drawable surface type defacto standard than create an imaginary perfect one like we seem to be doing on this list. Running code is king Great, lets go with VML, supported on the majority of desktops out there, used by high profile sites such as Google, It's a much better option albeit more complicated than canvas. Jim.
Re: [whatwg] Canvas element - Keep It Simple
On 4/24/05, Henri Sivonen [EMAIL PROTECTED] wrote: On Apr 23, 2005, at 22:16, dolphinling wrote: There's one implementation, and one implementation in testing builds. It would also be an easy change to make for those implementations (and they could still keep support for the old way if they need). The release date of Tiger is very near. Safari will ship with canvas. So? What's that got to do with the Web Applications Standard? Once it is out, you can't pull it back. It's never been in a published standard, the specification still states that it's subject to change. I'm very disappointed that the do not implement in released software has been removed without any discussion on the list of the maturity of the specification, but that's just the normal high handed approach of the working group. But even without that, there's no need to bless a poor implementation decisison simply because one minority browser has implemented it and used it solely in non-web content. If successful shipped implementations is what matters, then there's lots of successful IE extensions that do the same as canvas and other elements which it would be much more sensible to go with. Jim.
Re: [whatwg] Canvas element
On 4/22/05, Henri Sivonen [EMAIL PROTECTED] wrote: On Apr 22, 2005, at 18:00, Jim Ley wrote: so should be in a rendering language like CSS? If you value hard-line anti-presentationalism over pragmatism. Er, There are very good reasons why the presentation is split, the most important of course being accessibilty, it's clear from this list that people prefer being able to draw on-top of any element, or perhaps just an img element, and I'm sure that's not from any anti-presentationalism, but simply because they don't see efficient ways to author a canvas element in a backwardsly compatbile accessible manner. Repeatedly in WF2, new elements have been rejected due to their difficulty in implementing in IE6, why is canvas different? (and yes we could implement it in IE6 without much difficulty) Jim.
Re: [whatwg] Updating Location Bar for RPC Type Apps
On 4/22/05, Olav Junker Kjær [EMAIL PROTECTED] wrote: Brad Neuberg wrote: Whenever I implement a DHTML (Ajax?) type app that needs to talk to the server without refreshing the client, such as through a hidden iframe or an XmlHttpRequest object, I always wish that I could update the window location bar to show a bookmarkable and copyable URL, but update it in such a way that it _doesn't_ refresh the browser or change it's location (window.location.href changes the location). You can do this by changing the fragment, e.g. set window.location to: http://www.rojo.com/manage-subscriptions#sortby=TAG; This is useful for changing to a new bookmarkable state on the client side without reloading the page. Hmm, but then you need client-side intelligence to test the hash portion of the string, and then make subsequent requests to get the relevant data from the server. The original suggestion is much more powerful than that, as it allows the server to respond directly to a request. I've certainly wanted this, a sensible compromise is to only be able to set the query portion of the url. Jim.
Re: [whatwg] Scripting Tweaks
On 4/21/05, Dean Edwards [EMAIL PROTECTED] wrote: Ian Hickson wrote: Speaking of setTimeout, where is this defined? http://whatwg.org/specs/web-apps/current-work/#settimeout OK. That's twice in one day. I'm off to read the WA1 spec It's rather odd though, as it's been defined such that the mozilla implementation will be non-conformant, either the mozilla implementation will need to change to be conformant - breaking compatibility with existing scripts. Or mozilla will not be able to be conformant. Jim.
Re: [whatwg] Scripting Tweaks
On 4/20/05, Dean Edwards [EMAIL PROTECTED] wrote: Speaking of setTimeout, where is this defined? Nowhere, and in fact the string method is the commoner implementation, there are a number of implementations which do not support a function reference. uniqueID is very useful, I to use it all the time for patterns such as your hashtable of objects. I certainly support the idea, and with the strong issues that closures of DOM objects have in IE, it's even more valuable. It's certainly a pattern I would rather encourage in the dabblers who are always on the team. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 8, 2005 8:18 AM, Henri Sivonen [EMAIL PROTECTED] wrote: No. The proposed doctype !DOCTYPE html PUBLIC -//WHATWG//NONSGML HTML5//EN activates the standards mode in IE6. The proposed string that MUST appear as the first line of a WHAT-WG document is... please do not call it a doctype unless it is a doctype, see even people on the list are confused by using this! Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 7, 2005 11:51 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 7 Apr 2005, Anne van Kesteren wrote: Entities. Or is that problem going to be solved by: use UTF-8? (Which would be something I wouldn't disagree with, although for mathematical symbols it might be a pain to enter them.) In my world that is solved by no longer claiming that HTML is an SGML application. So please state that clearly in the specification. Can you also explain the point of the !DOCTYPE ... gibberish that the specs require at the top of documents? What are they doing, please remove them, they serve no purpose whatsoever. Or if they do serve a purpose, document what the purpose is. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 7, 2005 12:03 PM, Ian Hickson [EMAIL PROTECTED] wrote: They trigger standards mode in modern browsers. The current one for WHATWG specs is: Will the spec explain this some more, in particular could you document what standards mode is, and exactly how user agents should use this doctype to trigger it? Would it not be better to just require WF2/WA user agents to render it in this standards mode you talk of? Or at the very least use something that would not confuse people into thinking that it is an application of SGML or XML. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
Or at the very least use something that would not confuse people into thinking that it is an application of SGML or XML. Do you want to replace NONSGML with THIS-IS-NOT-SGML? No, I want to replace !DOCTYPE - with something completely different, the whole point that anything that looks like an SGML (or XHTML) doctype will confuse users into thinking that it is an application of SGML. I see no reason to continue only the odd model of rendering mode switching - especially without what this is exactly being defined in the spec. when as only new implementations will be written supporting WF2 a simple html WHATversion=2 like mechanism can be used, this will leave it in a much stronger position for going forward. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 7, 2005 6:59 PM, Henri Sivonen [EMAIL PROTECTED] wrote: On Apr 7, 2005, at 09:58, Lachlan Hunt wrote: I don't think SGML validation is part of What WG conformance requirements. I thought Hixie has specifically said he doesn't bother with DTDs. Hixie is simply the editor of the spec, this thread has shown clearly that many people contributing to the WHAT-WG work do use DTD's, indeed we already have a volunteer for creating a doctype, in fact it's only at this (supposedly) late stage that we've suddenly been told there's not one. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 7, 2005 8:30 PM, Henri Sivonen [EMAIL PROTECTED] wrote: On Apr 7, 2005, at 21:49, Jim Ley wrote: this thread has shown clearly that many people contributing to the WHAT-WG work do use DTD's To me it seemed that you argued that DTD validation is more useful than other conformance checks as long as the other checks are vaporware From which you can clearly conclude I do use DTD validation as part of my QA process. All the people who have said that DTD validation is absolutely useless haven't bothered to describe their QA processes at all. Maybe we could hear about these QA techniques rather than just saying how crap the existing tools are, rather than the sudden proposal to seriously reduce the amount of automated QA available to WHAT-WG adopters. If there was a different proposal on how WHAT-WG documents be QA'd then I'd certainly be happy to see DTD validation disappear. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 7, 2005 9:22 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 7 Apr 2005, Jim Ley wrote: From which you can clearly conclude I do use DTD validation as part of my QA process. All the people who have said that DTD validation is absolutely useless haven't bothered to describe their QA processes at all. Nobody is stopping anyone from using DTDs. If it's not an SGML applicaiton, you most certainly are. However, the main issue, is How are people going to ensure they're producing valid WHAT-WG documents? Your proposal is to throw away all the existing QA resources and leave a user with none, unless they happen to have the time and the resources to understand a lot of dense prose and author a DTD from it. Something which very few people are going to be able to do. So I'll ask once again, how do the WHAT-WG believe authors of WHAT-WG documents will produce conformant ones? Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 6, 2005 11:22 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: However, I disagree with that statement anyway. Validators should not be non-conformant simply because they only do their job to validate a document and nothing else. Absolutely, if there is a continued use of a doctype, then a validator is absolutely correct to validate to it, so either the validator should remain conformant, or the doctype should be dropped. (or explicitly marked as this is not an SGML or XML doctype it is simply some cargo cult you should include as your first line) I don't see any reason why such a statement needs to be included at all. Neither do I, it's completely unreasonable to say that an incredibly useful QA tool is non-conformant, simply because the editor doesn't consider those benefits in the same way. In any case, assuming I'm still the editor when the parsing section gets written, Why wouldn't you be? Because they might present the work to a standards body who gets a new editor? or some disgruntled reader may ... hmm, no, let's not go there... HTML5 will most likely stop the pretense of HTML being an SGML application. What the? I disagree with that. HTML should remain an application of SGML, and browser's should be built to conform properly. Fully agree. Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 6, 2005 11:41 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: Lachlan Hunt wrote: and the mostly undefined error handling, what about HTML 5 will be so incompatible with SGML to warrant such a decision? One example: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-January/002993.html the specication has not currently taken this into the specification, and there has been no other support in the mailing list for doing this? This is clearly an example of how existing browsers are non-conformant, and simply making it conformant just blesses browsers in the future to continue violating specs safe in the knowledge that the spec will get changed to suit them, rather than the reverse. Exactly what's happened with CSS, do we really want to do it with HTML too? Cheers, Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 6, 2005 3:41 PM, Olav Junker Kjær [EMAIL PROTECTED] wrote: Lachlan Hunt wrote: There are three types of conformance criteria: (1) Criteria that can be expressed in a DTD (2) Criteria that cannot be expressed by a DTD, but can still be checked by a machine. (3) Criteria that can only be checked by a human. A conformance checker must check (1) and (2). A simple validator which only checks (1) is therefore not conformant. One of the motivations of the WHAT-WG stuff, is that existing users don't have to change their existing tools, processes and understanding, now all of sudden we're removing one of the most valuable QA tools available today, based on some spurious notion that all these existing users don't understand the QA tools limitations. Firstly I think the conclusions that the audience for WHAT-WG stuff doesn't understand the limitations of the validator is sustainable - where's the evidence? And secondly, there won't be any QA tools at all if the validator isn't one of them, so we'll be getting even more crap published, and far from cleaning up the correctness, we'll just have a whole new load of crud to rubber stamp as valid in WF2, now I realise it's to the advantage of existing browser manufacturers to rubber stamp complicated heuristic behaviour they've already solved into a spec (it prevents new entrants from coming along) but how is it to the advantage to the rest of us - understanding specifications becomes harder and harder and relies on the fact that we knew what happened before... I simply cannot see the point in removing one of the few QA tools that actually exists for HTML, and would like to hear the actual argument for doing so. (as this is a seperate issue to if application of SGML is something that it would be) Jim.
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 6, 2005 10:05 PM, Henri Sivonen [EMAIL PROTECTED] wrote: On Apr 6, 2005, at 15:10, Lachlan Hunt wrote: XHTML variants of HTML 5 must be a conformant XML document instead, though I noticed that is not the case with square brackets in ID attributes in section 3.7.2 of WF2 That's not a problem if you don't claim they are ID attributes but attributes that happen to be named id. Which would mean we also have to start redfining DOM, so document.getElementById(...) is defined to work against things that happen to be named id and not just things that are ID's. Is it really worth going down this road? Jim.
Re: [whatwg] [WF2] Objection to autocomplete Attribute
On Wed, 30 Mar 2005 12:03:44 + (UTC), Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 30 Mar 2005, Lachlan Hunt wrote: Instead of a password, the bank issues you with a hardware device that computes a one-time password that changes every minute. Which changes the security to a physical security problem To be honest, the fact that there are still banks that use PIN codes or passwords for Web-based access is frightening. I don't find it frightening at all, the levels of this sort of fraud aren't high, and the problem is phishing. The cost and inconvenience of lugging around yet another passkey device (4 bank accounts with different banks, a couple of corporate VPN's) is enough such that I simply wouldn't use a bank (or a banks internet access) if they forced such a device on me. The hardware methods don't stop phishing (they do make it slightly harder in that the removal of the money has to be immediate meaning there's more accounts needed to transfer money into) but as they're not perfect and are a considerable extra cost, can't be taken into a lot of countries of the world, I can't see the attraction. Jim.
Re: [whatwg] WF2 changes: uri-url, ERROR_* constants dropped; status update
On Wed, 23 Mar 2005 17:32:28 +, Dean Edwards [EMAIL PROTECTED] wrote: I like the repetition model but maybe it needs more work. But not much more. I feel we are very close to a simple yet useful mechanism. If we did separate it into a separate module then we would have time to tweak it... My current view, which I've not had time to fully write up yet, is that the repetition model proposed is effectively unimplementable in IE in an efficient manner. The requirement to iterate over every element in the document looking for the attribute, and the requirement to iterate over every attribute in every element in the template looking to perform the substitution when inserting make it all very, very slow (the IE attributes collection contains more than just the attributes defined, and setting attributes like name are not actually well supported) I think whilst it's a good generic solution, implementing it in script for a specific solution gives such a large performance improvement that the IE script emulation approach will be impractical. I've yet to come up with any suggestions to improve this though. Cheers, Jim.
Re: [whatwg] ContextAgnosticXmlHttpRequest: an informal RFC
On Thu, 10 Mar 2005 10:18:16 -0600, Doron Rosenberg [EMAIL PROTECTED] wrote:
Well, the code in Mozilla is well tested and already used in the wild.
Could you point me at the tests?
URL:
http://lxr.mozilla.org/seamonkey/source/extensions/webservices/docs/Soap_Scripts_in_Mozilla.html
says they're at:
URL: http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/tests/
called soap* - but there's none of that name there? I can't get it to
work anyway,
var soapCall = new SOAPCall();
soapCall.transportURI = http://jibbering.com/;;
soapCall.encode(0, chicken, urn:Jibberjim, 0, null, 0,[]);
soapCall.verifySourceHeader = true;
soapCall.asyncInvoke(
function (response, soapcall, error) {
alert(response.message+'\n\n'+error)
}
);
makes no request for the webserver xml doc, but does post to the
server... Obviously I'm doing something wrong, the example and test
files will turn it up I'm sure.
The benefit of the extra request is that we don't fetch any data
unless we are allowed to. In your model, we would fetch the XML, and
then check if there is a header that allows us to pass it to the user.
If that's the only complaint, then an extra HEAD request on the same
resource would be even more efficient (no data transferred), and no
less secure. A get on an unrelated document should not be necessary.
And I think easy delpoyment is important. Cross domain is only really
important for intranets.
If this is the case, why not go down the IE cross domain intranet
deployment model, which is very well understood and very well used by
millions of people rather than a new method, that's only relevant to
SOAP (in this case) ? Or indeed even the current mozilla security
model which is also used?
Jim.
