Re: [whatwg] A thought:
James Graham wrote: ... Consider the example of a webmail application. These often allow messages to be retrieved by clicking on hyperlinks containing the subject line*. This is apparently all well and good because retrieving a message is sounds like a simple GET-friendly operation. Except that the act of retrieving a message often has the side effect of marking the message read in some way (not an unsafe operation per-se but one that should only be initiated by a user). You're right, it's not an unsafe operation. A Web browser does this with links anyway, when it gives visited links a different color from unvisited ones. That doesn't mean it should, early-Arena-like, present all links as buttons. All the Webmail application is doing is retaining visited/unvisited presentation across whatever computer you log in to your Webmail from -- which is part of the point of it being a Web application in the first place. So that's not really a good example of a non-idempotent action, and therefore not a reason for specs to condone non-idempotent links. -- Matthew Thomas http://mpt.net.nz/
Re: [whatwg] A thought:
Henri Sivonen wrote: One of the issues is that doing the Right Thing means creating a form, and that effects the UI, There'd be a design bug somewhere if the UI wasn't affected! When something looks like a link to, the user has a good reason to expect that following the link causes a safe retrieval operation. When something looks like a button, the user has a reason to understand that pressing the button may cause an unsafe operation. I'm not sure that users (the vast majority of users who haven't even heard the term RFC, let alone read one) have any particular expectation for the safety of clicking on a link. The fact that so many webapps use links for unsafe operations kind-of supports that view. Plus, design _is_ important in these things and submit-style buttons don't always make good UI. Consider the example of a webmail application. These often allow messages to be retrieved by clicking on hyperlinks containing the subject line*. This is apparently all well and good because retrieving a message is sounds like a simple GET-friendly operation. Except that the act of retrieving a message often has the side effect of marking the message read in some way (not an unsafe operation per-se but one that should only be initiated by a user). So with the current HTML spec, one has the option of a) using hyperlinks to retrieve messages so sticking with a familiar and well understood UI paradigm but violating HTTP and breaking e.g. precaching in UAs, b) using some sort of form for retrieve messages so making the UI ugly and probably harder to navigate, especially for users familiar with approach a), or c) requiring scripting for basic functionality (retrieving messages and/or marking read messages as read). Allowing would, AFAICT, solve this kind of problem. *I don't claim this is the optimum UI but it is certianly much the most common UI I have experienced in webmail applications.
Re: [whatwg] WebApps spec, chapter 7.1.1.9 "Images"
On Sat, 7 May 2005, Jens Bannmann wrote: > > The note at the end of chapter 7.1.1.9 saying "All canvases implement > HTMLImageElement, so canvas elements can be passed to the drawImage > methods" looks like it's superfluous, now that HTMLCanvasElement no > longer inherits from HTMLImageElement. The rest of the spec, e.g. the > second paragraph of that chapter, was already changed accordingly. Good catch. Removed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A thought:
Henri Sivonen wrote: On May 7, 2005, at 01:55, Ian Bicking wrote: I was just thinking about the recent problems introduced by the Google Web Accelerator following links that have side effects (the typical [delete this] stuff). Links like that are objectively wrong according to RFC 2616 (HTTP 1.1). Google is free to follow those links without being responsible for the side effects. I think it's sufficient to note that this is an *extremely* common pattern, regardless of RFC 2616. I think this might be a constructive place to discuss why it is so common, and what could be provided to web developers so they can do the right thing, but I don't think much is achieved by just saying that the majority of web developers are wrong. And it's the majority of web developers that use these kinds of links, regardless of spec. Heck, Google uses these kinds of links. One of the issues is that doing the Right Thing means creating a form, and that effects the UI, There'd be a design bug somewhere if the UI wasn't affected! When something looks like a link to, the user has a good reason to expect that following the link causes a safe retrieval operation. When something looks like a button, the user has a reason to understand that pressing the button may cause an unsafe operation. Without Web Forms and nested forms, it *is* a bug to effect the UI in the ways that would be required, because isolated controls cannot be put inside the context of a larger form that submits to a different location and performs a different action. The only way to do that now would be with Javascript, which would submit a form that existed elsewhere on the page. It is also made more difficult by the fact that a form is a block-level element, and so has even more effect on the layout of the page. And there's other much more safe operations that also cause side effects. For instance, links that reorder items -- they aren't very dangerous, you don't really have to warn users implicitly about their effects, but it will cause problems if a UA clicks these links without direct user request. I think there is a continuum, and by forcing safe state-modifying actions to look different it has caused many developers to do things that are unsafe with regard to HTTP, so that their UIs better represent (in those developers' opinions) the functionality they are providing. Developers use many techniques to indicate what a control will do. Generally links give them more flexibility in how they indicate this, I'm just trying to explain why this "incorrect" practice is so common. I haven't thought about it a lot before now, so I'm making it up as I go along, but emperically there must be reasons. It then would be helpful to give developers tools that address those reasons, but allow them to use POST the way they should. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
Re: [whatwg] [html5] tags, elements and generated DOM
On Apr 18, 2005, at 15:28, fantasai wrote: Henri Sivonen wrote: On Apr 17, 2005, at 04:58, fantasai wrote: For those of us writing HTML by hand, this is not a practical solution, particularly when invisible characters are involved. Invisible characters aside, I don't want to go digging through a Unicode character map every time I want → or τ. That's not an issue for HTML where entities get tag soup treatment anyway. I didn't say that authors should not type entity references in XML. I said that the entity references should be resolved before the data travels from the server to the client. So, when is my document going to get preprocessed? I certainly don't want to bother fussing with it every time I fix a typo. If there is no CMS and the server served raw files, the preprocessing would have to happen while editing or in an editor save hook. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] [web-apps] 2.7.8 The i element
On Apr 16, 2005, at 17:53, Ian Hickson wrote: On Sun, 17 Apr 2005, Lachlan Hunt wrote: Actually, in HTML5 is currently defined as having specific semantics: http://whatwg.org/specs/web-apps/current-work/#the-i So does "i" now stand for "instance", instead of "italics"? At least until someone argues otherwise. :-) Everybody knows it originally stands for "italic". Who would you fool by claiming it stood for something else? For browsers, and the element name is just a string. They don't care of English words. The default rendering will have to be italics anyway due to ample legacy content. No matter what to write in the spec, for all practical purposes will mean "italic". I think acknowledging this would be in line with the descriptive approach the WHAT WG specs tend to take when it comes to features that have been already interoperably implemented. What's the pseudo-semantic trickery good for? Will hard-line anti-presentationalists who spread false propaganda about being deprecated suddenly embrace if WHAT WG claims it stands for a different English word? In that case, would you want to differentiate between ordinary titles and real citations? Or is that something that the class attribute could handle, if needed? I don't know. What do people think? I'd define meaning a title of work (not a person and not limited to quoted works). -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] elements containing other block-level elements
On Apr 11, 2005, at 19:50, Ian Hickson wrote: I probably agree with this, but I'm not 100% sure. What about blocks around e-mails: Access via the DOM also affects styling. Also, if UAs have to parse it in the old way, what's the point? It's not increasing the semantics, since the UAs have to parse it the old way. ...or something. Then again, that does look pretty bad. I'm not a big fan of . In fact, I stay away from it and use ... with no-break spaces for code snippets. For mail archives, I suggest supporting format=flowed, which means should not be involved. On Fri, 8 Apr 2005, Henri Sivonen wrote: I see the option are: a) Banning XHTML divergence for everyone. b) Behaving as if a) was the case and barfing at XHTML that cannot be serialized as HTML. c) Bending over backwards in order to track whether a given piece of data can be serialized as HTML and whether there is a future need for a given piece of data to be serialized as HTML. Option a) doesn't seem popular and implementing c) would be a pain, which seems to leave b) for those who serialize as HTML. Of course, the reason why one would want to serialize as HTML is IE (and Lynx). Agreed. Is option b acceptable to you? I suppose that realistically it has to be, because enforcing a) doesn't look like a realistic option. :-/ It would help if WHAT WG published a RELAX NG schema for the text/html-compatible subset of the XHTML flavor. That would make appropriate barfing easier. It would also facilitate the implementation of text/html flavor conformance checkers. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] A thought:
I'm strongly against anchors submitting data. Main use of it would be for clueless designers that have no idea about usability and UI consistency. This illustrates the problem better than words: http://browsehappy.pl/i/apost.png -- regards, Kornel Lesinski
Re: [whatwg] A thought:
Ian Bicking wrote: I was just thinking about the recent problems introduced by the Google Web Accelerator following links that have side effects (the typical [delete this] stuff)... So, is this a suggested solution to that problem... A related extension might be a method attribute to anchor tags. One might expect [delete this] to do a post request to "form" with a request body of "delete=10". Or it could do a post with an empty request body, but unfortunately a large number of web frameworks ignore URL variables in post requests. The Google Web Accelerator will still be broken (the method attribute wouldn't magically appear on all the many applications out there), ...which doesn't really solve the problem at all? From what I understand, it's not Google's web accelerator that's broken, but rather the implementations that use links instead of forms and depend on JavaScript for confirmation. Anything that unconditionally depends on JS is broken by design, not the tool that doesn't make use of it. Ideally, if JS is used for confirmation like in the apps that I've heard are affected, the script should modify the URI in some way to pass additional confirmation information (eg. appending a ...&confirmed=1 parameter). In the absence of that confirmation, the server could then send a page with a form requesting confirmation. -- Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
Re: [whatwg] A thought:
On May 7, 2005, at 01:55, Ian Bicking wrote: I was just thinking about the recent problems introduced by the Google Web Accelerator following links that have side effects (the typical [delete this] stuff). Links like that are objectively wrong according to RFC 2616 (HTTP 1.1). Google is free to follow those links without being responsible for the side effects. One of the issues is that doing the Right Thing means creating a form, and that effects the UI, There'd be a design bug somewhere if the UI wasn't affected! When something looks like a link to, the user has a good reason to expect that following the link causes a safe retrieval operation. When something looks like a button, the user has a reason to understand that pressing the button may cause an unsafe operation. One might expect [delete this] to do a post request to "form" with a request body of "delete=10". -1. Makes the safety of links non-obvious to users. can be implemented in Javascript fairly easy. But shouldn't. The Google Web Accelerator will still be broken It is not broken! The server-side apps that use GET for non-safe, non-idempotent operation are broken. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] WebApps spec, chapter 7.1.1.9 "Images"
The note at the end of chapter 7.1.1.9 saying "All canvases implement HTMLImageElement, so canvas elements can be passed to the drawImage methods" looks like it's superfluous, now that HTMLCanvasElement no longer inherits from HTMLImageElement. The rest of the spec, e.g. the second paragraph of that chapter, was already changed accordingly. Best regards, Jens
