Re: [whatwg] More YouTube response
On 6 Jul 2010, at 15:24, Marques Johansson wrote: A 200 response or partial 206 responses that returns less than the full requested range is not handled by browsers in a consistent or usable way (for this purpose). Only Chrome will continue to fetch where the previous short 206 response left off (request 1-10, server replies 1-5, request 6-10, server replies 6-10). The HTTP spec isn't clear about whether UAs should take this behavior - and so they don't. It might be easier to get that fixed in browsers, than to get spec+implementation of a completely new feature. Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. You could respond with HTTP/1.0 and close connection. You could split movie into separate video files and hide that fact in the player's UI (sort-of like Apple's HTTP live streaming). -- regards, Kornel
Re: [whatwg] HTML 5 : The Youtube response
I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient: A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened. B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor. C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5. D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms. E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W). F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode. I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate. Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen — text and UI elements displayed by attacker will look noticeably different. -- regards, Kornel
Re: [whatwg] Allowing in attribute values
A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. You just need two extra states in the parser (toggled on or '). I wouldn't call that very costly. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of the body element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then . But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. Conversion of HTML to text is more complicated than that - e.g. you shouldn't turn foobrbar into foobar, but you have to keep foobbar as foobar. Implied body is allowed, you should extract img alt, you have to decode entities, etc. I think check for a single character is just a drop in the ocean in such code. And if you're not concerned about accuracy of conversion, you can ignore the fact that is allowed too. It's just going to be yet another tradeoff among many other, much bigger ones. Also take into consideration that even if was forbidden in the spec, it wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd still have to support it if you wanted to parse markup from the web. Allowing it in the spec and how the browser should behave if it is anyway are two different things. If you're parsing markup from the web, you have to support invalid markup that browsers accept, not merely pure markup that spec allows. There are reasons to disallow , but I'm not convinced that parsing performance is one of them. -- regards, Kornel
Re: [whatwg] Allowing in attribute values
On 24 Jun 2010, at 14:11, Benjamin M. Schwartz wrote: Why would it simplify parsing? It greatly simplifies parsing when you just want to extract entire tags, without immediately parsing the attributes. If you mean parsing with regular expressions, then I think that's a bad practice and shouldn't be encouraged. Also take into consideration that even if was forbidden in the spec, it wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd still have to support it if you wanted to parse markup from the web. OTOH if you want to parse only markup that is under your control, you can self-impose that restriction. However, I see other argument against allowing in attributes: it helps to catch unclosed attributes early: a href=foo -- regards, Kornel
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís
csol...@gmail.com wrote:
Hello! I've been noticing a problem in many HTML5 test apps, very
especially games. When the directional arrow buttons are pressed, the
screen scrolls.
This is a problem that, as far as I know, Flash had solved by changing
the focus of the application to the app. Is this doable in HTML5?
Yes. It's possible already — page just has to return false from keypress
handler:
window.onkeypress = function(){return false}
That's just one line that, unfortunately, many web-based games forget to
include.
--
regards, Kornel Lesiński
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 08:44:09 +0100, Jonas Sicking jo...@sicking.cc wrote: Agreed on both accounts. Both these suggestions add a lot of complexity to the platform and we should avoid it if at all possible. To the extent that if there is lots of broken sites out there because they happen to use attribute names that collide with HTML5, but only partially match the HTML5 behavior, then we should consider renaming those attributes in HTML5. I don't agree that there are lots of broken sites. My main browser is Opera and I haven't noticed that problem yet. The fact that there are some sites using 'required' attribute proves that it's a good, intuitive name. HTML5 is likely to outlive those broken sites. I think it would be shame to change to worse name for HTML's lifetime just to avoid temporary problem with some sites. -- regards, Kornel Lesiński
Re: [whatwg] WebSockets: UDP
On 1 Jun 2010, at 11:12, Erik Möller wrote: The use case I'd like to address in this post is Real-time client/server games. The majority of the on-line games of today use a client/server model over UDP and we should try to give game developers the tools they require to create browser based games. For many simpler games a TCP based protocol is exactly what's needed but for most real-time games a UDP based protocol is a requirement. Games typically send small updates to its server at 20-30Hz over UDP and can with the help of entity interpolation and if required entity extrapolation cope well with intermittent packet loss. When a packet loss occur in a TCP based protocol the entire stream of data is held up until the packet is resent meaning a game would have to revert to entity extrapolation possibly over several seconds, leading to an unacceptable gameplay experience. It seems to me the WebSocket interface can be easily modified to cope with UDP sockets (a wsd: scheme perhaps?) and it sounds like a good idea to leverage the work already done for WebSockets in terms of interface and framing. The most important distinction between ws: and wsd: is that messages sent by send() in wsd: need not be acknowledged by the peer nor be resent. To keep the interface the same to the largest possible extent I'd suggest implementing a simple reliable 3-way handshake over UDP, keep-alive messages (and timeouts) and reliable close frames. If these are implemented right the interface in it's entirety could be kept. Only one new readonly attribute long maxMessageSize could be introduced to describe the min path MTU (perhaps only valid once in connected mode, or perhaps set to 0 or 576 initially and updated once in connected mode). This attribute could also be useful to expose in ws: and wss: but in that case be set to the internal limit of the browser / server. SCTP would be ideal for this. It's connection-oriented, but supports multistreaming (can deliver messages out of order, without head of line blocking). http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol -- regards, Kornel
Re: [whatwg] Image resize API proposal
On 24 May 2010, at 22:09, David Levin wrote: that even if it was implemented everywhere, this solution involves readback from the GPU which, as Chris mentioned, is generally evil and should be avoided at all costs. This I'm not qualified to comment on, though. To the best of my knowledge, GPUs are magical boxes that make things go faster via pixie dust. ;) Thanks for your opinion. :) Chris is qualified so are other people whom I've spoken to who have said the same thing, so using the gpu is not pixie dust in this particular scenario even though folks would like to be believe it so. I think GPU readback is a red herring. It's an operation that takes milliseconds. It's slow for realtime graphics, but it's not something that user is going to notice when uploading images — users are not uploading hundreds of images per second. If UA can parallelize decoding, scaling, encoding and sending, the operation can be very fast and memory-efficient, even if scaling is done very slowly (it won't have noticeable impact as long as it's not slower than uploading). JPEG can be efficiently decoded at fraction of its size — without full decode and scale process. This process also needs only fraction of memory required for full scaling, which might matter on low-end mobile devices. Letting UA utilize this feature may give huge performance gains. Scaling isn't the only operation desirable — in some cases users might also want to crop the image (e.g., to upload only their face as an avatar), and cropping interface needs to be platform-specific — on touchscreen devices I'd rather use gestures than select-by-click'n'drag interface typical for desktop. I think scaling of images before upload might be left completely up to UA. From site's perspective it could look like user simply selected scaled-down file. It could even be done declaratively — site could define desired size and whether user should be asked to crop the image: input type=file accept=image/* max-image-size=1000x1000 crop=allowed Actually, I wish UAs offered scaling even for plain input type=file, because I don't expect every site with image upload to add extra code for resizing. -- regards, Kornel
Re: [whatwg] RFC: input type=username
On 4 May 2010, at 09:07, timeless wrote: On Tue, May 4, 2010 at 10:08 AM, Eitan Adler eitanadlerl...@gmail.com wrote: 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? Sites may not work correctly with autofill because their login forms are too complex or confusing the auto-fill feature (and sometimes login forms are complex/unusual – users may have option to log in to different sections of the site, with different security options). I don't think type=username is good solution, but I agree that autofill needs help. Sites often use e-mail address as login. There would be conflict between type=email and type=username. I have wiki that has password field on edit page (you don't log in before starting an edit, you simply type password before submitting the change). It completely confuses Opera's autofill which tries to save page title field as login name. Perhaps new values for autocomplete attribute would do the trick? autocomplete=login, autocomplete=not-login? (latter meaning you can autocomplete, but don't autofill when logging in). It would be nice to have autodiscovery for OpenID logins: input type=url autocomplete=login? autocomplete=openid? Another problem is the same login form appearing in multiple places on the site (usually slighly different form is part of site's layout, and different one is presented when user is forced to log in). Sometimes autofill sees such forms as same, and sometimes it doesn't. Auto-fill information is often lost when sites are redesigned. It would be nice if autofill could remember values from registration form and automatically use them for logging in. Users usually aren't asked to log in after registering, so there's no opportunity for the browser to save login details immediately. For this something like Realm value in HTTP auth would be helpful (perhaps as an attribute on form or input). Same realm across different forms would allow browser to save same details for all of them. -- regards, Kornel
Re: [whatwg] Form-based HTTP Authentication Proof of Concept
On Thu, 25 Feb 2010 16:00:37 -, Timothy D. Morgan tmor...@vsecurity.com wrote: As a follow up to my paper advocating HTTP authentication over cookies [1], I've built a simple sample application which demonstrates how a combination of XMLHttpRequest and response code tricks can be used to achieve form-based login, logout, and authenticated password changes in the four most popular browsers: http://www.vsecurity.com/download/tools/fbha-poc_0.1.zip Note that this is achieved without using any checks to determine what browser is being used. While this is promising, I still think we should have an HTTP-based log out mechanism. In addition, the proposed W3C change to XMLHttpRequest authentication behavior will make this code much simpler. FIY a while ago I've implemented proof-of-concept as well, but by using URLs with login/password: http://geekhood.net/auth/ Those two approaches combined could offer solution with good user experience and working non-JS fallback. -- regards, Kornel Lesiński
Re: [whatwg] Suddenly, ~40% of IE users get HTML5 Theora with no effort
On Fri, 05 Feb 2010 20:47:35 -, David Gerard dger...@gmail.com wrote: http://www.atoker.com/blog/2010/02/04/html5-theora-video-codec-for-silverlight/ http://arstechnica.com/open-source/news/2010/02/nuanti-brings-html5-and-ogg-theora-video-to-silverlight.ars The 40% is from the blog post at the top. There's also Cortado Theora player which can work for those who don't have Silverlight, but have Java. I've tested it - it's good enough for small videos (too slow for HD unfortunately) and can be used to implement basic video interface. -- regards, Kornel Lesiński
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On 4 Feb 2010, at 17:44, Michal Zalewski wrote: If there's no HTML, there's no need for a sandbox, so the simplest solution is just to escape the s and s. Which people fail at, big time. There are 50,000+ entries on xssed.com, many of them against big sites presumably developed by skilled developers with the help of sophisticated frameworks - microsoft.com, google.com, amazon.com, ebay.com, etc. It is a really low-effort tweak to accommodate it here, and it may offer a very significant security benefit, so...? The problem comes from lack of escaping of any kind, so change in escaping method will not fix the problem, i.e., Hello $unescaped_name is as vulnerable as: Hello iframe sandbox srcdoc=$unescaped_name I think the difference is huge; in a typical web framework, you need to explicitly escape every single piece of potentially dangerous attacker-controlled input to stay safe - and because people tend to do some validation at input stage, it's very difficult to audit for it. Escaping also needs to be very different depending on the context (URLs need to be encoded differently than HTML parameters, and differently than standalone text). So even though your framework may provide several escape() functions, it's very easy to get it wrong, and people constantly do. OTOH, if your framework provides a get_token() function, there's really not that much to using it properly. That's problem with the frameworks (a big one, admittedly). However, there are templating engines that escape all variables, everywhere, by default, and this solves the problem very well. Addition of token-based sandbox won't improve anything in cases where authors forget to escape or wrongly assume that input is already filtered/escaped or harmless. If someone forgets to add escape(), why would they remember to add sandbox? Additionally sandbox will cause new security problem in all current UAs, so for plain text I don't see any benefit at all. However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name: sandbox-$token.../sandbox-$token where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: $token:sandbox xmlns:$token=…/$token:sandbox -- regards, Kornel Lesiński
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On 5 Feb 2010, at 14:19, Lachlan Hunt wrote: where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: $token:sandbox xmlns:$token=…/$token:sandbox No, you couldn't use a namespace like that, because then the sandbox element would not be in the HTML namespace, and thus would not have any known semantics. Eh, I've left out namespace URI, because I don't like to type it. Here's complete example that applies HTML semantics: div xmlns=http://www.w3.org/1999/xhtml; dd02c7c2232759874e1c205587017bed:sandbox xmlns:dd02c7c2232759874e1c205587017bed=http://www.w3.org/1999/xhtml; h1HTML/h1 /dd02c7c2232759874e1c205587017bed:sandbox /div -- regards, Kornel
Re: [whatwg] window.print() when printing is not supported
On Mon, 28 Dec 2009 11:54:00 -, Olli Pettay olli.pet...@helsinki.fi wrote: So I think it *might* make sense to throw some error if printing isn't supported. Or should browsers which don't support window.print() just not have print() method in the window object? (problem is that I'd guess everyone just expects .print() to be there) Why would page need to know if printing works? What (useful) thing could it do if it detects failed print? If all you want is to display error when printing fails, that's a UA issue. Why burden all sites with handling of error they can't fix? UA can signal the error, and can do it better, e.g. offer option to configure a printer. I'm afraid that even letting pages know whether printing is available might have negative consequences. I can't print anything from computer I'm using at the moment, BUT if I need to print something, I can save page/document and print it from another computer. If pages could detect that my computer can't print, they could wrongly assume I can't print anything at all, and hide print-related options from me. I'd hate if ticket sites automatically decided to snail-mail me tickets without offering option to print them myself. -- regards, Kornel Lesinski
Re: [whatwg] hgroup functionality absorbed into header?
On Sun, 18 Oct 2009 08:54:59 +0100, Ian Hickson i...@hixie.ch wrote: Your version with split h2 seems to use it only for visual effect. Not just visual, but presentational, yes, pretty much. It also makes it clear how to generate the outline. I don't understand how presentational h2s make outline clear. I thought they're an exception that didn't work simple outline algorithm: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Foutline=1#outlineresult and hgroup exists to resolve ambiguity caused by presentational use of headers. I still think that subtitle (subheader, tagline) would be just as effective, less confusing and less likely to break outline when used improperly... How is h2 confusing? h2 alone isn't. hgroup is the source of confusion. * Difference between hgroup and header is not obvious. It wasn't to me when I first saw them, and this isn't first thread about them. * Makes meaning of hx overloaded (sometimes it's a header that affects outline and level or other headers, sometimes it's a subheader that doesn't do anything that header would). Have you seen this post? http://www.onderhond.com/blog/work/the-hgroup-tag I think it sums up problems quite well. I think something like subtitle is just as likely to be misused as hgroup, to be honest. Sure, but it's much more fail-safe. If you use header instead of hgroup or fail to use hgroup, you may significantly change structure of the document. You can't make much damage with subheader. Sections will remain correct and at worst you'll add wrong subtitles to headers. My proposal for processing of subheader: * look for first hx preceeding subheader in tree order (depth-first starting with last child) [makes any subheader after hx work] * abort and ignore subheader when search crosses section boundaries [prevents misplaced subheader from being associated with wrong section]. Optionally: * if hx is an ancestor of subheader, associate subheader with that header The last rule allows: h1subheaderThe magnificent/subheader HTML 5 specification/h1 which addresses one of use cases you've mentioned a while ago when hgroup was discussed. Also, it has a much poorer legacy (backwards compatibility) story. Both solutions have problems. I don't think ones are much worse than the others. hgroup breaks the outline, subheader is ignored. Without CSS h2s will be too large and have too big margins. subheader will not get special rendering, but at least will look like block element (hx and p typically surrounding it will cause this). One might use psubheaderb if non-CSS display is a concern. With CSS subheader will work fine and doesn't limit styling possibilities. hgroup's content model doesn't allow any non-header elements, so one can't add any extra hooks for styling: hgroup h1/ div!-- add fancy border around subheaders? -- h2/ h2/ /div /hgroup Another thing - can you write XPath query that extracts all headers from the document? Without hgroup it's simple. With hgroup I'm not sure if I could manage to write correct query. -- regards, Kornel Lesinski
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, 23 Jul 2009 19:32:28 +0100, Eduard Pascual herenva...@gmail.com wrote: I don't think there's any value in having the spec take a stance like this. It's a matter of taste, IMO. While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they *should* quote attribute values. I think this requirement is even less relevant for authoring tools: * It's not a problem for tools to use unquoted attributes in a perfectly safe manner. * Not all code generated by tools is intended to be edited by humans, and in such cases shorter code is likely to be preferred over human-readable code. * Tools that offer editing of HTML source code may (and often do) have syntax highlighting and validation. -- regards, Kornel Lesinski
Re: [whatwg] input type=url allow URLs without http:// prefix
On Sun, 12 Jul 2009 09:46:19 +0100, Bruce Lawson bru...@opera.com wrote: As it's very common for people to drop the http:// prefix on advertising, business cards etc (and who amongst us reads out the prefix when reading a URL on the phone?) I'd like to suggest that input type=url allows the http:// prefix to be optional on input and, if ommitted, be assumed when parsing. The spec explicitly allows that actual value seen and edited by the user in the interface is different from DOM value of the input, so browsers are free to prepend http:// automatically (and IMHO should – DSK-253195). -- regards, Kornel Lesinski
Re: [whatwg] nostyle consideration
On Tue, 16 Jun 2009 11:51:05 +0100, Aryeh Gregor
simetrical+...@gmail.com wrote:
noscript is a very poor solution, and nostyle would be too. You
should use graceful degradation/progressive enhancement instead (in
both cases).
Graceful degradation is not necessarily possible with JavaScript. For
instance, consider a real-time game written in JavaScript.
True, but noscript doesn't allow implementation of games either.
What matters is cases where fallback is possible, and where nostyle
would improve it.
Sometimes noscript can be used for graceful fallback, too. For
instance, if a script normally generates an element dynamically when
needed, the element might be placed statically inside noscript so
that it always appears if script is disabled. (For instance, a
Nationality form in a field that only appears if a radio control is
changed from the default of U.S. Citizen.) Without noscript, the
only way I know of to allow graceful fallback is to do something like
hide the element onload, which will make it briefly visible.
It doesn't have to be briefly visible. Don't use onload, but an inline
script:
div id=hideme
scriptdocument.getElementById('hideme').hidden = true/script
(in)visible content…
/div
If your page uses DHTML a lot, and has fallback in many places, there's
nice trick for it:
head
scriptdocument.documentElement.className += script-supported/script
style.script-supported .dhtml-fallback {display:none}/style
--
regards, Kornel Lesinski
Re: [whatwg] nostyle consideration
On Mon, 15 Jun 2009 21:26:21 +0100, Thomas Powell tpow...@gmail.com wrote: 1) Head Usage nostyle meta http-equiv=Refresh content=0;url=/errors/stylerequired.html /nostyle 2) Body Usage nostyle h2Warning: Styles required for correct rendering/h2 /nostyle Purpose of this element seems to make lack of CSS not my problem instead of providing meaningful alternative. This is not helpful for users without CSS. It only helps authors to discriminate against them, and I'm strongly against it. Comments? noscript is a very poor solution, and nostyle would be too. You should use graceful degradation/progressive enhancement instead (in both cases). -- regards, Kornel Lesinski
Re: [whatwg] Question on (new) header and hgroup
On Sat, 06 Jun 2009 04:00:28 +0100, Ian Hickson i...@hixie.ch wrote: I don't think hgroup will be used often enough to justify calling it just h. Ok, but what about subheader? (subtitle, tagline?) The purpose of hgroup is to imply that hx is a subtitle. That's quite an indirection. An explicit element would be easier to understand: h1Dr. Strangelove/h1 subheaderOr: How I Learned to Stop Worrying and Love the Bombsubheader Also it could accept only phrasing content, so it would be easier for validators to catch when authors confuse it with header. It doesn't require changes to styling of hx, and can be given appropriate size with h1 + subheader CSS selector. -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Sun, 24 May 2009 17:40:21 +0100, Mike Wilson mike...@hotmail.com wrote: Aryeh Gregor wrote: You should spell out the existing problem carefully and in great detail, including existing solutions or workarounds, to get the best response. I certainly intend to do this once I get feedback on whether this subject is relevant for HTML5, or any other whatwg spec (preferrably from people involved in authoring these). Time is limited and I would like to only spend this effort if applicable to spec work. It depends what solution is chosen - browser behaviors and HTML elements/attributes are in scope of HTML 5, but HTTP methods and headers not so much. I don't think refresh is a big deal. I've been using refresh/resubmit as an easy example so that everybody knows what I am talking about. Hm, now I don't :) Can you re-state the problem you want to be solved? I thought you wanted to avoid browsers asking question whether they should re-submit POST. When/if this subject seems to relate to the HTML5 effort, I would like to contribute to a larger discussion on these kinds of topics. If the problem affects web applications and browsers, then that's probably good place to discuss it. -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Sat, 23 May 2009 12:29:56 +0100, Mike Wilson mike...@hotmail.com wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Browsers could make it possible by implementing history mechanism exactly like HTTP/1.1 specification suggests in section 13.13, i.e. going back in history should never cause resubmits, so there shouldn't be anything to ask about. Users should simply see previous state of the page, just like in case of GET. Do you think that solution suggested by RFC 2616 13.13 is not appropriate? Is Opera's solution of this problem not good enough? -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Sat, 23 May 2009 15:38:02 +0100, Mike Wilson mike...@hotmail.com wrote: Do you think that solution suggested by RFC 2616 13.13 is not appropriate? It does not define what to do at page refresh, only history traversal, as far as I can see. Sorry, I've assumed you were talking about Back button only. In case of Refresh it depends whether user realizes implications of re-submitting. If browser designers don't believe that pressing Refresh button states intent clearly enough, then I think asking the question might be justified. As creator of application you can solve this dylemma: * If it's not safe to resubmit, use status 303. I know it's not very convenient, but can be implemented reasonably well and works with existing browsers. * If it's safe to resubmit, use PUT method (allowed in HTML 5), which is idempotent by definition. -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
On Fri, 22 May 2009 21:48:28 +0100, Mike Wilson mike...@hotmail.com wrote: Thanks for expanding on my previous mail, Jonas, but I was assuming that everyone on this list was aware of the PRG pattern and its existing support in browsers. With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. As far as I understand the resubmit problem is just sign of poor implementation that violates SHOULD NOT in the HTTP RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 This problem can be elegantly solved within existing standards: Opera simply goes back in history without resubmitting forms, and resubmits only when user clicks standard Reload button (or F5, etc.) -- regards, Kornel Lesinski
Re: [whatwg] Removing the need for separate feeds
On Fri, 22 May 2009 09:41:43 +0100, Eduard Pascual herenva...@gmail.com wrote: For manually authored pages and feeds things would be different; but are there really a significant ammount of such cases out there? I can't say I have seen the entire web (who can?), but among what I have seen, I have never encountered any hand authored feed, except for code examples and similar experimental stuff. I maintain hand-authored Atom feeds on few websites. It's not a problem if feeds are updated rarely. On websites without CMS copyingpasting few tags once a month feels like less work than moving website to a CMS or writing XSLT :) Despite that I'm not excited about Ian's proposal. In these scenarios I often want content of the feed to be different than content of the page, e.g. feed says I've added article about Foo., but page has Newest articles: Foo, Bar, Baz. -- regards, Kornel Lesinski
Re: [whatwg] Removing the need for separate feeds
On Fri, 22 May 2009 07:01:51 +0100, Ian Hickson i...@hixie.ch wrote: It doesn't collect the blogroll or the blog post tags yet, mostly because I'm not sure how to do that. Any suggestions of improvements are naturally welcome. There's hAtom that solves this problem already, and appears to have been proliferated by popular blogging software: http://search.yahoo.com/search?p=searchmonkeyid%3Acom.yahoo.page.uf.hatom but I doubt that many users take advantage of it. Almost all of these pages have standard feeds as well (and all of them can provide them via hAtom2Atom proxy). Maybe a better approach would be to extend hAtom or define extraction in terms of hAtom? (e.g. make div class=hentry and article interchangeable?) For each article element article that does not have an ancestor article element That excludes possibility of syndicating article's comments from markup like this: body article post articlecomment/article articlecomment/article /article /body Feed with only single entry post or post comment comment would not be useful. OTOH it may be useful to include all nested comments in a single feed: articlecomment articlecomment reply/article /article Another problem is that algorithm cannot create summary. Perhaps summary could be assumed if there's alternate link and article doesn't contain more than one header? Or has entire contents wrapped in blockquote? I haven't noticed any way to exclude articles from the feed (except hack articlearticle.../article/article). I may have news that's not important enough to justify notification of all subscribers. Are trackbacks and tweets appropriate for article? I might want to show them on my page, but wouldn't want to repost them in my feeds. -- regards, Kornel Lesinski
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008 05:26:47 -, Ian Hickson [EMAIL PROTECTED] wrote: http://www.w3.org/TR/1999/NOTE-authentform-19990203 [...] I don't really understand what problem the above solves that isn't solved better by SSL. I agree that if real security is desired, SSL is the only way to go. However given that most login forms on the web send passwords in the clear, other problems were more important than security. Form + Digest avoids these SSL problems: * Does not negatively impact performance. In TLS handshake lots of messages are going back and forth, so this can't be fixed by beefing up servers' CPUs. * Does not need access to server's configuration, and generation, installation and renewal of certificates. Redistributable software can support it out of the box, on almost any server, without manual installation steps. Additionally, it's better than new WWW-Authenticate: HTML authentication mechanism: * It's compatible with existing non-HTML HTTP clients. * Although its security is weak compared to SSL, it's a step up from forms + cookies. * It's easier to sell: It will allow bots to log in doesn't sound very desirable. It will protect your users' passwords against passive eavesdropping sounds better. I don't think WWW-Authenticate: HTML is a significant improvement. It doesn't offer anything to existing websites/browsers. It's primarily targetted for non-browser UAs, but it's not compatible with them. If UAs are required to parse HTML, they could as well look for form with a single password field. -- regards, Kornel Lesinski
Re: [whatwg] a and button
On Sun, 19 Oct 2008 16:09:11 +0100, Håkon Wium Lie [EMAIL PROTECTED]
wrote:
button style=text-decoration: underline; color:blueW3C/button
It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.
http://www.w3.org/TR/css3-ui/#appearance
a {appearance: button} should do that.
In current browsers:
form method=get action=url style=display:inlinebutton/form
is very close to a link.
--
regards, Kornel Lesinski
Re: [whatwg] Safari-compatible input type=search
On Tue, 30 Sep 2008 12:40:23 +0100, Andy Lyttle [EMAIL PROTECTED] wrote: I would like Apple's input type=search adopted as an official standard, maintaining Safari compatibility. Comments? I like type=search. Special search box style is used throughout Mac OS X and Mac-centric sites try to fake it with borderless inputs that often end up looking broken. Windows has now a standard search box look too, so type=search would be good for intuitively looking search boxes across platforms. I'm in favor of placeholder on input type=search. It may be a bad UI, but it is used very often regardless. Standarizing it at least gives more control to UAs and frees authors from writing potentially buggy scripts (I haven't figured out yet how to write one that's not annoying on Opera Mini). I suggest ignoring onsearch and incremental attributes. They can be replaced with combination of oninput and onchange. I also don't like results and autosave. They're a bit confusing (if autosave=yes became popular, it would cause a mess). It can be abused (autosave=google's + script that puts site's own keywords just before user submits search). Such things are best controlled by browsers/users. To disable autosave authors could use autocomplete=off. -- regards, Kornel Lesinski
Re: [whatwg] The sizes= attribute for rel=icon
On Wed, 28 May 2008 13:07:50 +0100, Ian Hickson [EMAIL PROTECTED] wrote: I'm afraid that this could cause trouble (every visitor downloading icon that's 20–300 times larger than typical favicon). Why not use rel=application-icon or rel=appicon? I don't understand the question. link rel=icon is currently used for favicons. Favicons are expected to be small (in byte size). Current browsers always download favicons on every website. If page author adds high-quality image using rel=icon (like Vista's 100KB icon or Leopard's 300KB monstrosity), it may significantly increase site's traffic (these icons will be downloaded by every visitor rather than only those who create a shortcut). e.g.: link rel=icon sizes=16x16 href=tinyicon.png link rel=icon sizes=256x256 href=hugeicon.ico In current browsers this will not work as expected - browsers will download the big application icon, which is going to be order of magnitude larger (in byte size) than a favicon. Using rel=application-icon instead of rel=icon would avoid this problem. Another solution would be to suggest that authors specify favicon as last in the tree order (example it the spec lists favicon first). -- regards, Kornel Lesiński
Re: [whatwg] link rel=icon width= height=
On Thu, 08 May 2008 03:17:38 +0100, Ian Hickson [EMAIL PROTECTED] wrote: I've added a sizes attribute to link for the icon keyword. The spec now contains: If multiple icons are provided, the user agent must select the most appropriate icon according to the media and sizes attributes. If there are multiple equally appropriate icons, user agents must use the first one declared in tree order. Does this disallow composing .ico files from multiple separate files? UAs like Fluid or Prism can't know which sizes OS is going to use, so all valid ico sizes are 'equally appropriate'. Also this algorithm doesn't match current browser behaviour, is this intentional? I did a quick test with a bunch of random favicons: * Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide Leopard's monsterous 300KB icons) and displays last icon loaded, * Firefox 3b5 picks last icon regardless of attributes. It loads all icons when I reload page after restoring session. * WebKit nightly and Fluid pick last icon that has type attribute (even if type is bogus), or just last if none have type. I'm afraid that this could cause trouble (every visitor downloading icon that's 20–300 times larger than typical favicon). Why not use rel=application-icon or rel=appicon? I don't like the any keyword. SVG icons are scallable, but it's not the same as being usable at any size. For example Tango icons project provides PNG for 16, 22 and 32px icons in addition to SVG, because lines and finer details in SVG become illegible at small sizes. Does the specified size imply that UA is required to display icon at given size only? (i.e. is any obligatory to have icon scaled at all?) What if sizes attribute is absent? -- regards, Kornel Lesiński
Re: [whatwg] Script, style and backwards compatibility
On Fri, 09 May 2008 00:50:20 +0100, Samuel Santos [EMAIL PROTECTED] wrote: In order to validate a page as valid HTML/XHTML you need to escape inline script when using characters like . You can use: /*![CDATA[*/ /*]]*/ It's compatible with both HTML and XHTML. -- regards, Kornel Lesiński
Re: [whatwg] link rel=icon width= height=
I don't think it's that important to specify exact icon sizes. Authors won't bother to accurately provide such detailed information, and applications don't need it anyway. iPhone shouldn't be a concern here. It isn't limited to 59x60 icons—Apple's own website uses 129x129 (http://www.apple.com/apple-touch-icon.png) and current EDGE network iPhones won't use anything else than rel=apple-touch-icon. My suggestion is to simply define rel=application-icon without extra attributes. There isn't much bandwidth to be saved. These icons are going to be downloaded only once. 128x128 PNG icons take only 20-30kb. Large PNG file + favicon for smallest sizes may be good enough in most cases. In cases when icon design doesn't scale well, authors could provide additional .ico/.icns files. When website provides application icons (not favicon) in .icns or .ico files, I think it can be reasonably assumed that these files contain all sizes that are needed for desktop icons, and it doesn't matter which exactly. -- regards, Kornel Lesiński
Re: [whatwg] link rel=icon width= height=
On Mon, 05 May 2008 23:36:51 +0100, Aaron Boodman [EMAIL PROTECTED] wrote: There isn't much bandwidth to be saved. These icons are going to be downloaded only once. 128x128 PNG icons take only 20-30kb. Without hints as to which file contains which size, the user agent must download up to four separate images before using them. It doesn't have to download four images. For purpose of instant preview, UA can display first file it downloads. And you don't have to use many files, because larger files can (usually) be scaled to smaller sizes. Large PNG file + favicon for smallest sizes may be good enough in most cases. In cases when icon design doesn't scale well, authors could provide additional .ico/.icns files. Why should web developers have to settle for good enough, while desktop application developers get to create many differently sized icons optimized for use in different contexts? I didn't say authors have to settle for good enough. When one file isn't good enough, authors could provide additional ico/icns which can have best quality OS can handle, e.g: link rel=icon href=favicon.png type=image/png !-- 16 or 32px -- link rel=application-icon href=appicon.png type=image/png !-- 128px, ~25kb -- link rel=application-icon href=appicon.ico type=image/x-ico !-- possibly all sizes between 16 and 256px, ~90kb -- UA could assume that ico/icns offers better quality on platform that supports this file format and also that this file is going to be larger (because it contains set of images as opposed to single image). When website provides application icons (not favicon) in .icns or .ico files, I think it can be reasonably assumed that these files contain all sizes that are needed for desktop icons, and it doesn't matter which exactly. I don't think that ico or icns format is going to be the common case. These formats require specialized software to create correctly, whereas any image editor can create pngs. There are free, open-source tools to convert between .ico and set of PNG images. OS X comes with Icon Composer and there's 3rd party IconBuilder that works on MS Windows. Favicons in .ico format are popular and supported by all major browsers today. -- regards, Kornel Lesiński
Re: [whatwg] Referer header sent with a ping?
On Tue, 12 Feb 2008 21:54:25 -, Philip Taylor [EMAIL PROTECTED] wrote: It's quite a different situation when the Referer is used as a security measure in deciding to trust a user's request, where false negatives can have significant consequences (like editing data via cross-site request forgery). That is the situation where a ping mustn't introduce new risks. I looked for some examples of code that checks the Referer for security, and found: [...] That's interesting. In that case attack outlined on Mozilla's list is even less likely to succeed than I thought. So maybe a less abusive approach would suffice: * if ping is cross-domain, always send Referer * if ping originates from the same domain, don't send any Referer at all -- regards, Kornel Lesiński
Re: [whatwg] createImageData - new ImageData() ?
On Sun, 10 Feb 2008 23:25:51 -, Ian Hickson [EMAIL PROTECTED] wrote: That would mean that passing ImageData around between two canvas elements doesn't always work as expected. I think that's highly undesirable. Is there any implementation where we know this will the case? Not today, but why preclude it? Implementations could get higher quality renderings on canvases that get resized dynamically, by using a bigger backing store. What's wrong with what we have now? It's very easy to write code which assumes that size of imageData is the same as size given in canvas width height (I know, because I did it :) Since the ratio is system/browser-dependent and 200dpi screens aren't popular yet, such bug may be easily overlooked/ignored and get widely deployed. The difference in sizes isn't intuitive. For example if browser doubled number of pixels in ImageData only when user used zoom, I think authors would rather think that browser's zoom is buggy. I think that by default getImageData should return data with same size as specified in width/height attributes of canvas. There might be another method (getImageScreenData?) or method argument that returns all pixels of canvas. ImageData can be made portable between canvases by adding aspect ratio field or additional width/height fields given in CSS pixels. -- regards, Kornel Lesiński
Re: [whatwg] Revised Plan for Server-sent DOM events
On Sat, 05 Jan 2008 06:51:29 -, Henry Mason [EMAIL PROTECTED] wrote: - Unnecessary dependency on DOM Events This feature is inherently event-based. I think it does make sense to re-use existing framework for event handling. However, I haven't found use-case for remote triggering of standard events, like mouse and keyboard events. I always use my custom events, because I don't want to couple server-side code with details of particular user interface. - Redundancy with already existing techniques, especially XMLHttpRequest It's much simpler to use and allows browser to manage the connection. I propose that we remove support for non-message events; that is, allow only events with MessageEvent interface. +1 Scripts that need that functionality can create wrapper on client-side that will dispatch other types of events. The critically cool part, however, is that since MessageEvents store their domain and URI origin, it will be safe to allow for cross-domain messaging through this server-sent events. I don't see how it makes cross-domain messaging safe. Without Access-Control mechanism, what would prevent malicious site from reading event-source of e.g. users' gmail chat? (variant of CSRF attack) -- regards, Kornel Lesiński
Re: [whatwg] webforms2: new hash attribute for input ?
On Thu, 16 Aug 2007 19:49:27 +0100, Julien TOUCHE [EMAIL PROTECTED] wrote: Unfortunately this will not secure browsing session, because once user is authenticated, server will have to use cookies which could be stolen and used to impersonate the user. cookies are another part of the problem which needs to be secured too (httpOnly, secure, limited to one IP, and so on ... but could be overcome too) Limiting cookies to one IP is problematic with proxies (may block users behind proxy farms, protection is weakened for users of ISP's proxies). Still need to standardize other algorithm than in rfc2617 which specifies only md5 (better to add sha1/sha256/sha512) Fortunately RFC 2617 allows addition of new algorithms (I haven't checked if that doesn't break popular clients though). rfc2617 also defines a salt-like with nonce, which is a very good point, but it seems to give the same problem said in first mail: it need server to have passwd in clear to be able to compare against a changing hash (if nonce is used) ... Maybe I'm missing something, but AFAIK server only needs to store H(A1), which may be generated without nonce if 'MD5' (rather than 'MD5-sess') algorithm is used, and this does not eliminate nonce from the algorithm, because it's used in computation of 'request-digest'. another problem is you can't block brute attacks. banks account are, in general, blocked if you miss them 3 times and after you need to call the bank. Digest makes it difficult to count exact number of invalid login attemts (as legitimate requests may get rejected because of stale nonce or nonce count), but generally it is possible to implement and when client exceeds allowed number of attempts, server may start responding with 401 or 403 to every request from that user/IP. -- regards, Kornel Lesiński
Re: [whatwg] webforms2: new hash attribute for input ?
On Wed, 15 Aug 2007 16:08:51 +0100, Julien TOUCHE [EMAIL PROTECTED] wrote: input type=password hash=sha256 name=mypass / so the browser transmits only the corresponding hash of the given value. Unfortunately this will not secure browsing session, because once user is authenticated, server will have to use cookies which could be stolen and used to impersonate the user. My suggestion is to kill two birds with one stone by marrying forms with Digest authentication (RFC 2617). Digest is already implemented in browsers, doesn't require storage of unhashed passwords, protects entire browsing session (with integrity checking of payload and stopping replay attacks) and can provide mutual authentication - it would be wasteful to re-invent and re-implement all that for forms. The dealbreaker in current Digest implementations is the user interface - looks unfriendly, can't be customized, website can't offer account registration until user cancels login and there's no logout mechanism. This can be solved by providing form controls that would log user in using Digest authentication: form method=digest input type=hidden name=realm value=my realm input type=text name=username input type=password name=password /form or input id=myusernameid input type=password authentication=digest realm=my realm username=myusernameid UI for logging out could be as simple as button type=logout, however implementation details are probably outside scope of HTML 5. -- regards, Kornel Lesiński
Re: [Whatwg] Request for HTML-only print link
On Sat, 28 Jul 2007 19:02:46 +0100, Sander [EMAIL PROTECTED] wrote: I don't see how that is good usability. Quite the contrary, because this approach means things work different on each website. That's confusing; incosistency makes things harder to use. A print method that works the same across web sites is much more usable. I don't think it's confusing as the browser's own print button is still there. If page provides it's own print button, user won't be sure if there was a real technical reason for doing this (and browser's print button won't work properly) or if just author felt it's nice having more buttons on his page. A man with a watch knows what time it is. A man with two watches is never sure. -- regards, Kornel Lesiński
Re: [whatwg] Entity parsing
On Fri, 15 Jun 2007 02:05:05 +0100, Ian Hickson [EMAIL PROTECTED] wrote: I've defined the parsing and conformance requirements in a way that matches IE. As a side-effect, this has made things like naiumlve actually conforming. I don't know if we want this. Rather not. This would break unencoded URLs: ?foo=barregion=baz → ?foo=bar®ion=baz -- regards, Kornel Lesiński
Re: [whatwg] include element
On Mon, 23 Apr 2007 23:19:49 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: This is an idea I have had floating around in my head for a while and a recent couple of threads reminded me I really need to post it here. Basic idea: The idea is basically an element like iframe but that renders the linked page Something similar has been proposed recently: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010801.html IMHO such includes don't solve the biggest problem of frames - that there's only a single usable URL and all actual content is in orphaned scraps of documents. Your use-case is a bit different, but I think such include will be commonly abused as a drop-in replacement for iframe. I suggest investigating further concept of ID overlays instead: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010805.html -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] wrote: By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it I'm a bit worried about this one - authors too often forget (or don't care) to add alt attribute, and this case gives it a different meaning. I think that for (2) there should be either magic alt value or some way of specyfing that alt was intentionally omitted, and not forgotten (special classname? presence of title attribute?). -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Sun, 22 Apr 2007 18:58:13 +0100, Kristof Zelechovski [EMAIL PROTECTED] wrote: For (2): alt=(Your browser does not display graphic images). What's the point? Users who rely on alt attribute know that already, and unless exactly that phrase is required by the specification (= bad for i18n), it won't be any use for bots either. I think presence of the title attribute (which might be empty) could be required if alt is omitted: img title= src=canyon.jpg or maybe: img alt=- src=canyon.jpg and role of img src=canyon.jpg should be left undefined, allowing UAs to use heuristics to guess it. -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Thu, 19 Apr 2007 21:07:09 +0100, timeless [EMAIL PROTECTED] wrote: As such, encouraging people to include alt tags means the difference between me knowing that there's an image I care to look at and not. If e-mail client automatically inserted [image was here] in the text part of e-mail, you would know that there were images, even without user providing better alternative text. I support opinion that it doesn't make sense to _require_ e-mail clients to bug users about alternative text. On the web rationale for alt text is that you can never know who will read your page. In case of personal e-mail you do know. Pictures sent in personal e-mails almost never have function other than the picture itself - alt text for vacation photos, to be really an alternative, would have to be an essay. -- regards, Kornel Lesiński
Re: [whatwg] [WF2] button without value= should perhaps use .innerText as value
On Sat, 14 Apr 2007 02:10:07 +0100, Simon Pieters [EMAIL PROTECTED] wrote: We currently don't have interop with IE and other browsers with regards to what to send to the server as the value of button. IE always sends .innerText as value. IIRC it's innerHTML, but I can't verify it at the moment. Is there really a noticable number of sites that rely on IE's broken behaviour? I doubt, because: * By sending contents of button instead of value, it doesn't provide much more functionality than input type=submit. * Styling of button is not an easy task, so it's unlikely to be used for its HTML contents - authors rather use input type=image or a href=javascript:sendform() * And worst of all - IE always sends all undisabled buttons. This makes value irrelevant, because you can't check which button was clicked anyway. -- regards, Kornel Lesiński
Re: [whatwg] IE/Win treats backslashes in path as forward slashes
On Wed, 11 Apr 2007 15:13:09 +0100, Gervase Markham [EMAIL PROTECTED] wrote: Looking through the spec again, there is nothing about backslashes in URI's path being treated as a forward slash, behaviour needed for compatibility for quite a few websites. I would be rather surprised if that were true, given that Firefox doesn't do it and I've never come across a website which broke for that reason. But maybe I live a sheltered life. Working for osiolki.net (site that blacklists IE-only websites), I've come across a few. http://www.google.com/search?q=site:osiolki.net+backslashfilter=0 (+ there are 4 more non-public cases). -- regards, Kornel Lesiński
Re: [whatwg] IE/Win treats backslashes in path as forward slashes
On Wed, 11 Apr 2007 14:02:39 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: Looking through the spec again, there is nothing about backslashes in URI's path being treated as a forward slash, behaviour needed for compatibility for quite a few websites. I think it can be added. RFC 1738 calls backslash unsafe (RFC 2396 unwise) character and says it must be encoded, so this change won't affect any valid URLs/URIs. I've tested how browsers handle path in img tag: IE6, Opera 9.2, Safari 2 translate \ to /. Camino (Gecko 1.8) and iCab 3 translate it to %5C. All browsers leave %5C alone, meaning that this change won't stop anyone from accessing resources that really contain backslash in the path (tested Apache2 on OS X 10.4). -- regards, Kornel Lesiński
Re: [whatwg] Anchor target-attribute extension to enable dom targeting
On Sun, 08 Apr 2007 19:17:55 +0100, Georges MARZIN [EMAIL PROTECTED] wrote: a href=inc/foo.frg target=#main_area Click here to dynamicaly load a text/html piece of code into the main_area identified dom node /a !-- somewhere in the same document -- div id=main_area/div The content of inc/foo.frg in not a complete html page but only a well formed xhtml piece of code like : div this content is dynamically loaded into a dom node, like ajax, but with a html extended syntax of the target property. /div IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. I think that much better and more powerful solution are ID overlays. The idea is to merge documents instead of completly including one into another. XUL has something like that: http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays -- regards, Kornel Lesiński
Re: [whatwg] Anchor target-attribute extension to enable dom targeting
On Sun, 08 Apr 2007 22:22:20 +0100, Georges MARZIN [EMAIL PROTECTED] wrote: IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. When the response will arrive, css rules will apply to the new content, and the result will be smart. Yes, in this regard it's much better than iframe. However it doesn't solve the worst problem of frames - that subpages become separated from essential parts of the document. I am interested with your solution of xul-like id overlay for merging documents. But I know this for xul, but not for html. How can it work ? I was just referring to the concept. Something similar could be made for HTML. I think there should be an additional requirement that every subpage specifies its parent page. This would allow user agents to reconstruct full document from any subpage. How about that? index.html: h1My page/h1 a href=subpage.html rel=overlayopen subpage/a div id=mainhello world/div I've used rel=overlay since you don't need to specify where should supage be included (elements with same IDs will be replaced). subpage.html: a href=index.html rev=overlaymy parent/a div id=mainsubpage/div This page has reV=overlay, which specifies the parent document. This has two roles: - a fallback that allows users and bots to find parent page that contains navigation and rest of the content - allows UAs that support overlays to rebuild complete page using this reference resulting DOM would be: h1My page/h1 a href=subpage.html rel=overlayopen subpage/a div id=mainsubpage/div It should be enforced that subpages contain rev=overlay link and that parent pages and subpages are mutually connected: If there's no rev=overlay link in the subpage or it has rev=overlay link that points to URL other than that of current page, browser should normally open subpage instead of overlaying it. For example if index.html contains: a rel=overlay href=orphaned.html and orphaned.html does not contain a rev=overlay href=index.html, browser should not overlay it (ignore the rel=overlay). When opening a page that has rev=overlay link, browser should load referenced page and overlay the current one on top of it. For example if user opens subpage.html as a standalone document (types the address, opens a bookmark) and the document contains: a rev=overlay href=index.html browser should load index.html and overlay subpage.html on it. And of course since DOM of pages gets shared, overlay should be subject to the same origin policy. -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold [EMAIL PROTECTED] wrote: there can always be browser defaults that take over, but by allowing authors the ability to override the browsers controls will allow for the flexibility of a) allowing for disabled controls (perhaps disabling fast-forward for training videos) Seems to me the user shoudl be in control here, not the author. If they want to fast forward, the browser lets them. I have no interest in enabling or even suggesting the use of the silly DVD type controls where you can't fast forward through the ads or the FBI notice. I find these annoyng myself as well, but I don't think specification could stop anyone from doing that. Authors use unskippable ads in Flash videos already. If video won't let them do the same, most likely they simply won't use video. -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Fri, 23 Mar 2007 10:24:30 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
Let's say there's http://example.com/example.html page which contains
embedded video:
...video src=video.ogg...
I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA to start playing the embedded video.ogg from 12:35.
That would be hard, because how would you identify which embedded
video or audio file on the example.html page this temporal offset is
referring to?
I think it might work like this: when play() is called on a video
element, and it hasn't been called on any other video element in this
document yet, read time from location.hash and call seek().
This would work with dynamically created video elements and would
probably be the best choice even if there are multiple video elements in
the document.
If such altered behavior of play() is not unacceptable, then that might
work:
http://example.com/[EMAIL PROTECTED]:35
Where myvideo part is interpreted as ID of element in the document (and
if there's no such element - assume document.body).
If the element is a video, then seek() that video.
If it isn't, then seek first video descendant of that element (something
like: (document.getElementById(myvideo) ||
document.body).getElementsByTagName('video')[0].seek(12*6+35000))).
My rationale:
* it doesn't require any changes to the document, so user can control
starting position in any document, even if author didn't think of such
possibility
* It's part of document's URL, not URL of the video file, so user doesn't
have to extract video file URL from the document and can still use the
page (which provides controls for the video).
* it can be implemented in JavaScript with current video API (also in
User JavaScript, but I think for interoperability it's important to be
part of the spec).
* it's orthogonal to server-side support for seeking
Also, it could be interpreted by the UA only, since
everything after # will not be transferred to the server.
Yes, that's intentional. It allows user to modify *any* URL without risk
of breaking it (some servers/applications may not like extra query
string). I think use of hash for this is appropriate - just like UA
scrolls HTML to given element, UA would scroll the video - it's just a
change of axis from Y to time :)
--
regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Fri, 23 Mar 2007 20:57:24 -, Silvia Pfeiffer [EMAIL PROTECTED] wrote: video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40 to provide the video segment between offset 12:35 and 20:40 video id=myvideo_4 src=video.ogg?id=section4 to provide the video from named offset section4 These provide the Web page author with the power to do offsets. How would that be used? Do you expect UA to change query string arguments when video.seek() is invoked? If src=video.ogg?t=0:12:35 is specified, how would user see the beginning of the video? http://example.com/example.html#myvideo_1?t=0:12:35/0:20:40 to provide the Web page with the first video playing section 12:35-20:40, It's fine although ofcourse I'm biased towards simpler and more compact syntax I've suggested :) These two URIs with fragment offsets would currently not work in a Web browser. However the set of URIs that I provided inside the video tag above already work through the Annodex framework for ogg files. What if server does not support it or site uses another video format? -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Thu, 22 Mar 2007 20:53:48 -, Silvia Pfeiffer [EMAIL PROTECTED] wrote: About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. I think we had in mind (at least I did) URL of the page that contains the video, not the URL of the video file itself. Because of this indirection it's completly up to UA to read fragment identifier and translate it into appropriate HTTP request for the video file (which could use Range header that's more proxy-friendly than query string). Let's say there's http://example.com/example.html page which contains embedded video: ...video src=video.ogg... I'd like to be able to construct URL like: http://example.com/[EMAIL PROTECTED]:35 that would cause UA to start playing the embedded video.ogg from 12:35. -- regards, Kornel Lesiński
Re: [whatwg] video element feedback
On Wed, 21 Mar 2007 18:31:29 -, Nicholas Shanks [EMAIL PROTECTED] wrote: Well besides the fact that fragment ids cannot start with a number nor contain a colon I've checked syntax for fragment identifiers in URIs (RFC 2396) and haven't found such limitation. If such fragments cannot match any current HTML IDs, that's even better. you have to consider the problem of multiple unequal representations. In this example equivalent content is not at the same time offset. Clicking the link should take you to the relevant place whether the UA is rendering the video, the audio or the transcript: On the other hand it depends on authors providing metadata. Most likely very few will do that, and even then provided chapters may not cover all interesting fragments in the video/audio. -- regards, Kornel Lesiński
[whatwg] Bookmarking videos
On Wed, 21 Mar 2007 20:19:24 -, Nicholas Shanks [EMAIL PROTECTED] wrote: On the other hand it depends on authors providing metadata. Most likely very few will do that, and even then provided chapters may not cover all interesting fragments in the video/audio. That situation isn't any different from ordinary HTML nowadays, most people don't even give all header-level elements unique ids, let alone individual paragraphs. But that doesn't mean the facility shouldn't be made available to those who want/need it. It is possible to implement it using JavaScript - you can read location.hash and seek() video appropriately. This however is a little help to users who want to bookmark videos or share links to certain parts of them - without a standard way of doing it UA's won't be able to provide UI for it. Even if you implement that for yourself using UserJS, you won't be able to share those links, etc. -- regards, Kornel Lesiński
Re: [whatwg] Attribute proposal: video autostart
On Mon, 19 Mar 2007 08:15:43 -, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
Automatic behavior in HTML has been traditionally expressed through
scripting. It's not hard to write a one-line script which automatically
starts playback, but solutions based on scripting are easier to
circumvent on the user side (and it's good).
If you intend to use user scripts, you can as well call stop() on
automatically started video elements.
-1 for |autoplay|.
I think it depends on whether video will be usable without scripting or
not. If current specification does not intend to require default UI, then
some JavaScript would be neccessary anway, so autoplay attribute doesn't
make any difference.
If video gets default UI and one could simply use video src=...,
then addition of something like
scriptdocument.getElementById('myvideo').play();/script would diminish
elegance and simplicity of video element.
--
regards, Kornel Lesinski
Re: [whatwg] Video playback UI
On Sun, 18 Mar 2007 18:52:35 -, Alexey Feldgendler [EMAIL PROTECTED] wrote: How about controls overlaid on top of video, which are visible only when mouse hovers it? Something like fullscreen controls in QuickTime Pro or iTunes 7. To ensure that video is always usable: * UI would be on by default (but visible on hover) * Author could disable it using attribute of video element * User could re-enable controls using context-menu or some other method (in case author disabled default UI and failed to provide usable alternative) -- regards, Kornel Lesiński
Re: [whatwg] Comments on the video element
On Sun, 18 Mar 2007 21:07:20 -, Mihai Sucan [EMAIL PROTECTED] wrote: If video elements would have native UIs, bloggers would be more attracted of it, and developers of video sites as well. In the above case, you'd only have: video src=http://www.youtube.com/v/id; I doubt YouTube would allow that. Such video (even with UI provided by browser) lacks features that YouTube probably would require: branding and link to their website. I think support for XSPF might be helpful in solving that problem. XSPF has image element which could be used as stand-in or overlay image and info elements for link to YouTube and video's page. -- regards, Kornel Lesiński
Re: [whatwg] video element proposal
On Fri, 16 Mar 2007 23:49:04 -, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... I think that nomenclature in WHATWG's API is much simpler and straightforward and that outweights benefit of appealing to authors experienced with SMIL/SVG. beginElement() may sound strange and confusing to authors, especially ones familiar only with W3C DOM (where names like getElementById or createElement are often used). OTOH anyone can guess what play() and stop() do. +--+-+ | Flash/ActionScript | WHATWG| +--+-+ pause() | togglePause() pause(true) | pause() pause(false) | togglePause() seek(s) | seek(1000 * s) time | position / 1000 This however is a good point - since Flash became de-facto standard for publishing video on the web, authors are likely to know Flash's API already. Having similar, but not exactly the same API may be source of mistakes. -- regards, Kornel Lesiński
Re: [whatwg] Video proposals
I think it would be useful if fragment identifiers in URL could specify starting position of video. This would let anyone to bookmark position in the video without having to worry about (lack of) site-specific navigation and UI for seeking. [EMAIL PROTECTED]:mm:ss (I'm not sure how should it be handled if video doesn't have an ID - maybe ID of any ancestor element could be used instead or fragment would affect any/first video on the page) The use case however is quite simple and common: If I'm watching long video and want to show interesting part of it to my friends (or bookmark it), I could right-click the video, choose Copy link to this video option and have URL with current playing position copied. -- regards, Kornel Lesiński
Re: [whatwg] Make th be a header cell for its row even for the first row
On Tue, 13 Mar 2007 20:29:09 -, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: Many pages use tables where only the first column are header cells, e.g.: table trthFoo tdBar trthFoo tdBar trthFoo tdBar /table With the current algorithm for assigning header cells to data cells, the first th won't be a header cell for any data cells. Can't 'scope=row' be used? It can, but in this case scope of row is so obvious, that it would be counter-intuitive if specification said otherwise. -- regards, Kornel Lesiński
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 17:46:43 -, Elliotte Harold [EMAIL PROTECTED] wrote: How so? Well, your article advocates sniffing specific user agents where the one written by Mark Pilgrim uses the Accept: header which was actually designed for this... Google, for one, is known for not supporting XHTML really well. I'm not doing content negotiation here. From HTTP point of view you are. There's one representation available. It is XHTML. We can send that to most browsers and they'll deal reasonably. Two I know of have problems (IE and Lynx) so we lie to them and tell them it's text/html. Use of Accept does not require you to return completly different representations, you can use it just like you used User-Agent. However Accept contains exactly the information you're trying to (and failing to) derive from User-Agent header. I am curious what problems Google has with XHTML. Then they deal. Last time I checked they were marking XHTML documents as Unknown format. Since Google certainly has engineers aware and capable of fixing this problem, Google must be ignoring XHTML deliberately. I suspect they support only what works for their customers and XHTML in XML mode doesn't work for vast majority of them. User-agent sniffing is a bad practice - it's inaccurate, hurts minority browsers and is not forward-compatible. Please change your method to use Accept header, so it won't be affecting any HTML-only user-agents (web is more than a handful of desktop browsers). Accept method will even work for MSIE and Lynx when/if they start supporting XHTML. Even your regular expressions for User-Agent aren't doing exactly what you intended, because mod_rewrite does not anchor patterns. -- regards, Kornel Lesiński
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 23:52:08 -, Alexey Feldgendler [EMAIL PROTECTED] wrote: Even your regular expressions for User-Agent aren't doing exactly what you intended, because mod_rewrite does not anchor patterns. While I totally agree that browser sniffing isn't a way to go, I must say that Accept headers cannot be used to resolve this because MSIE claims to support */* in the Accept header that it sends. And Googlebot claims to accept application/*. Despite that Accept header can resolve this issue. XHTML browsers include full application/xhtml+xml MIME type, so you can avoid false positives if you ignore wildcard matches in negotiation. While it's not perfect, I think it's still better than using User-Agent for the same purpose. -- regards, Kornel Lesiński
Re: [whatwg] video element proposal
On Tue, 06 Mar 2007 10:11:01 -, Gervase Markham [EMAIL PROTECTED] wrote: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? A script could easily fake video element using dynamically created object. That's almost what SWFObject/QTObject scripts do now (and that's probably de-facto standard for embedding interactive content since Eolas patent). I think in that case video is safest solution, because this gives acces to alternative content (which is broken in IE6's object) and allows script-controlled plugin detection and workarounds for bugs in plugins/browser. -- regards, Kornel Lesiński
Re: [whatwg] Geolocation in the browser
On Fri, 23 Feb 2007 15:15:13 -, Gervase Markham [EMAIL PROTECTED] wrote: Postcode would be easiest way to integrate location API with existing services (especially via userjs/greasemonkey, where using location-postcode database may be difficult). The problem with suggestions like this is that they require geocoding on the server side. Geocoding services are not always readily available; there's no free, unencumbered implementation I know of. And you need a different database for every country. API I've suggested allows browsers to provide various representations of the location, so there can be best effort on both sides. I guess I don't object to the browser returning this information additionally if it knows it - but lat/long should be the baseline, always-present info. But what about browsers that don't have access to GPS device nor geocoding service? These browsers could still return city and postcode information provided by the user and that could be enough for many applications (nearest branch locators, etc.). navigator.getGeolocation() would return location with best precision allowed by default (without asking user every time). If user set in preferences that every page can get location with 10km precision, that would be returned. I think it's better to ask every time and remember the precision allowed. I would certainly much prefer to know who knows where I am. Ofcourse there should be option to ask every time, but it can't be the only option. Some users may prefer not to be bothered and have location-based services just working. Also there are IPgeo databases, so some users may want to allow giving away information that has approximately same accuracy. -- regards, Kornel Lesiński
Re: [whatwg] Geolocation in the browser
On Wed, 21 Feb 2007 20:31:11 -, Ryan Sarver [EMAIL PROTECTED] wrote: var location = window.getLocation(); For some applications location given in format other than lat/long may be more useful and less privacy-sensitive. For example name of the city might be good enough if you order a cab from a nationwide company. Postcode would be easiest way to integrate location API with existing services (especially via userjs/greasemonkey, where using location-postcode database may be difficult). Additionally city/postcode information may be provided to desktop browsers by the user (for example Opera collects that information already). Also different applications may be satisfied with different precision of location (searching for nearest airport vs nearest starbucks :) There's also privacy problem with giving too precise location and usability problem with asking for user's permission every time. My proposal is: use navigator.getGeolocation instead of window.getLocation to avoid conflicts with existing functions (window object is a global namespace in JS) and to avoid confusion with window.location object. navigator.getGeolocation() would return location with best precision allowed by default (without asking user every time). If user set in preferences that every page can get location with 10km precision, that would be returned. navigator.getGeolocation(100) would request location that has precision of 100m or better. If user's default allowed precision is lower than the specified one, browser would ask for permission. Browser would be allowed to return location with lower precision than requested (if it doesn't have information precise enough or because user decided so). The function would return an object, which could be queried about various aspects of the location - name of the city, postcode, but also precision of location given (so applications would know if user is really exactly in the middle of the city or if browser only knows the city name). -- regards, Kornel Lesiński
Re: [whatwg] WF2: Non-validating submit buttons
On Wed, 24 Jan 2007 21:55:16 -, Simon Pieters [EMAIL PROTECTED] wrote: However, this doesn't solve the use case of saving an unfinished form server-side. Are there any real-world examples where you can save an unfinished form on the server and continue filling it afterwards, that also has required fields (when the form is finished)? I have never seen such a form. Saving incomplete forms is a recommendation in cite isbn=0-7357-1410-X ;) Devensive Design for the Web/cite which provides www.bankone.com as an example site that saves incomplete applicatios (I don't know however if that's via save button or just up to the last completed step). IMHO non-validating button makes sense for saving drafts of various kinds (webmail, blog post, wiki page). Another use-case is a preview button. Example: comment submission on a blog. You may require users to fill-in their name and e-mail address, but these fields aren't neccessary to display a preview of text formatting. -- regards, Kornel Lesiński
Re: [whatwg] E4X and attribute values
On Tue, 16 Jan 2007 12:59:56 -, Henri Sivonen [EMAIL PROTECTED] wrote: Is E4X allowed in event handler attribute values and in javascript: URIs? If yes, how can a UA know whether the E4X parse mode should be used? This can be explictly stated using Content-Script-Type HTTP header/meta and Mozilla's MIME type parameter: meta http-equiv=Content-Script-Type content=text/javascript; e4x=1 / http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6 http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.2.1 However since the e4x type parameter seems to be only affecting parsing of comments and CDATA inside script, it's irrelevant for attributes, so I think it shouldn't be required and E4X should work in attributes/bookmarklets by default. -- regards, Kornel Lesiński
Re: [whatwg] Hyphenation
On Tue, 09 Jan 2007 23:47:46 -, James Graham [EMAIL PROTECTED] wrote: FWIW this all makes just as much sense with dictionary replaced by stylesheet (stylesheets need to be kept in sync as new elements, classes and ids are used rather than new words). Not entirely. The layout and structure of the documents is not as variable as their content. And the solution that works for stylesheets (external file) has a problem: delays initial display or causes FOUC. With external dictionary there could be another FOUC - Flash of Unhyphenated Content. -- regards, Kornel Lesiński
Re: [whatwg] Hyphenation
On Tue, 09 Jan 2007 13:03:04 -, Leons Petrazickis [EMAIL PROTECTED] wrote: I would suggest that the first priority is getting a naive hyphenator into browsers. Since you only ever need hyphenation when full-justifying I disagree. It's also needed in narrow columns, even if they're left-justified and may be useful for very long words in general. Once that is in place, we can start thinking about special cases. I would suggest a hyphenation dictionary in the head of the document. Hyphenation dictionary supplied by the page seems like a good idea, but having it in head might cause some headaches in dynamic systems: * in some template systems adding anything to head is difficult * author may want to compose page from several independent fragments, possibly each having its own dictionary. Merging these dictionaries would either require some extra logic or cause duplicate entires (and authors won't like that waste). * One would have to keep in sync dictionaries and text (in practice there will be cases when dictionary lacks some words or contains words which aren't present in text any more) * syntax proposed is verbose and with entire dictionary repeated on every page that adds up to a substantial traffic And this problem can't be solved by using external file for dictionary, as it will either delay initial display of the page until dictionary is loaded or will require reflow of entire page. Therefore I suggest something possibly a bit more difficult to UAs - learn from the text in document. Having document with: The zoë-ven hypertext must ab-stain from grooming monkeys in an indefatigably questionable fashion. The zoëven hypertext must abstain from grooming monkeys in an indefatigably questionable fashion. UA would make note of words with soft hyphens and replace further non-hyphenated occurances with hyphenated ones: The zoë-ven hypertext must ab-stain from grooming monkeys in an indefatigably questionable fashion. The zoë-ven hypertext must ab-stain from grooming monkeys in an indefatigably questionable fashion. (decision whether this is visible in DOM or not is probably best left to implementation). As for the exceptions in hyphenation, I'm in favor of hyph element. -- pozdrawiam, Kornel Lesiński
Re: [whatwg] div as a wrapper for inline content
On Thu, 04 Jan 2007 00:58:34 -, Ian Hickson [EMAIL PROTECTED] wrote: What's the use case for div elements containing inlines? From microformats.org: div class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div It can be generalized to when div is used in place of elements with inline content model and which are not in HTML. The simplest example could be div class=h7. -- regards, Kornel Lesiński
Re: [whatwg] Detecting Web Forms for future proof scripts?
On Mon, 02 Oct 2006 17:00:02 +0100, Shawn Wilsher [EMAIL PROTECTED]
wrote:
Hopefully, you aren't duplicating work that has already been done here:
https://sourceforge.net/projects/wf2/
Granted, this is only for IE, but nearly half of your work is already
done then.
This project appears to be dead for over a year now. It seems to have at
least intention to support Gecko, but I couldn't get it to work properly
in Firefox.
I've ran into similar problem as the original poster. For inputs, buttons
and repetition there's an easy solution:
input.setAttribute('type','uri');
if (input.type != 'uri') alert('no native WF2!');
but it's a stretch to assume that support of certain input type means
support for all of WF2, so I'm curious how can one detect support for
other functionality.
--
pozdrawiam, Kornel Lesiński
Re: [whatwg] Detecting Web Forms for future proof scripts?
On Mon, 02 Oct 2006 17:37:28 +0100, Shawn Wilsher [EMAIL PROTECTED] wrote: This project appears to be dead for over a year now. It seems to have at least intention to support Gecko, but I couldn't get it to work properly in Firefox. Just because the project appears to be dead doesn't mean you should just disregard all the work that has been done with it before. It's original aim is only for IE (as stated in the description). However, it has a large amount of work already done - why reinvent the wheel? If I need just a feature or two, it's easier for me to write and maintain my own bit of code rather than rip it out of an unfinished, unstable code that I'm not familiar with. I'd love to use that script once it's production-ready. -- regards, Kornel Lesiński
Re: [whatwg] href on any element
On Tue, 29 Aug 2006 17:02:22 +0100, Francisco Monteiro
[EMAIL PROTECTED] wrote:
What practical use has this for Mr Joe Public?
Give me a really useful example in very simple wording!
Having data table representing list of items where large clickable area is
useful - i.e. inbox in a webmail, list of contacts, forum threads listing,
etc.
I've ran into this problem many times and seen many questions about this
on forums/usenet.
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
--
regards, Kornel Lesiński
Re: [whatwg] href on any element
On Tue, 29 Aug 2006 22:55:01 +0100, Matthew Raymond
[EMAIL PROTECTED] wrote:
Having data table representing list of items where large clickable area
is useful - i.e. inbox in a webmail, list of contacts, forum threads
listing, etc.
I've ran into this problem many times and seen many questions about this
on forums/usenet.
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
This can be accomplished by having a elements in each individual
cell...
Ofcourse it can, but it bloats code a lot. You have to add several
redundant links, add tabindex=-1 to avoid breaking keyboard navigation,
move all table and cell styles to anchors, and if cells contain block
elements you have to bloat your code even more.
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
People don't typically don't initiate a purchase in a user interface
by clicking on the product description.
Make it href=/info then. Sometimes it doesn't make sense to have
separate page for each listed detail.
Ofcourse you can live without href on every element if you apply a bit of
scripting and CSS tricks, but the same thing can be said about almost
every thing in WHATWG specifications.
It can have some backwards-compatibility. AFAIK XHTML/2 allows nested
anchors, so I'd use it like this:
tr href=..tda href=..anchor/a/tdtdno anchor/tdtdno
anchor/tdtdno anchor/td/tr
With some scripting (see first code in this post) this could work in
current browsers and had fallback for bots and non-JS agents.
--
regards, Kornel Lesiński
Re: [whatwg] Re: getElementsByClassName
On Tue, 06 Sep 2005 00:54:56 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
I fear that if we use a string that must be parsed, we will encourage
buggy implementations.
Not at all. Actually this should improve implementations, because same
parsing algorithm is used for both input string and class attribute.
Unfortunately in practice the two parts of that code are likely to be
completely unrelated parts of the codebase, so that reuse is unlikely.
Even if it isn't reused, such function is not a rocket science. Can't you
trust implementors to trim and split string properly?
For example I may want first to find set of classes I'd like to match
against. With solution I propose it's easy and intuitive to anyone who
used .className:
if (x) find += class1;
if (y) find += class2;
getElementsByClassName(find);
but with varargs function it's really cumbersome:
if (x) find.push(class1);
if (y) find.push(class2);
switch(find.length)
{
case 1: getElementsByClassName(find[0]); break;
case 2: getElementsByClassName(find[0],find[1]); break;
...
}
You can just do:
if (x) find.push(class1);
if (y) find.push(class2);
document.getElementsByClassName.apply(document, find);
...which seems much better to me than using a string.
It's the first time I see apply method used. I couldn't find it in
ECMA262-3 nor in WA1.0. Can you give me a hint where it's defined?
Why is that better than using string?
--
regards, Kornel Lesinski
[whatwg] getElementsByClassName()
I think variable number of arguments for that function may be cause of many problems. As far as I'm aware W3C DOM never uses functions with variable number of arguments, so design of getElementsByClassName() stands out. Functions with variable number of arguments are problematic in some programming languages, and because of that W3C may not want to include such method in future DOM specfications. Such design forbids any extensibility as well - it won't be possible to add new optional parameters to that function. I suggest that getElementsByClassName() should take only one parameter: string of space-separated class names. This may simplify implementation, because same algorithm can be used to get list of class names from input and from elements. It will also solve IMHO unclear case of getElementsByClassName(foo bar) matching bar foo. It would, as opposed to behavior where space is both separator and part of class name. -- regards, Kornel Lesinski
Re: [whatwg] [wf2] disabled default submit button
On Wed, 27 Jul 2005 12:03:04 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: In both situations all non disabled form controls are submitted. With (1) Opera and Firefox seem to be following the Web Forms 2 specification, but with (2) none of the browsers seem to be compliant. So Firefox is compliant, Opera is buggy and IE is non-conformant. I don't think that's a bug in Opera. That is design choice: in Opera 'default' submit button is dependent on which element has focus. Opera uses first submit button that is after currently focused element. This makes a lot of sense on forms like: select input submit value=confirm selection input file input submit value=upload this file input text input submit vaule=submit and go elsewhere In Opera after you fill each option and hit enter logical and useful action happens. If default submit button was always the first button, hitting enter would never end form, and you would be 'stuck' on the first one. I find Opera's solution very useful and I think it would be shame if Opera was made conformant with less sophisticated specification of default submit button in WF2. -- regards, Kornel Lesinski
Re: [whatwg] [wf2] disabled default submit button
On Wed, 27 Jul 2005 13:32:10 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Quoting Kornel Lesinski [EMAIL PROTECTED]: This makes a lot of sense on forms like: select input submit value=confirm selection input file input submit value=upload this file input text input submit vaule=submit and go elsewhere This represents essentially two forms. It does not make sense it all if a developer writes such forms. It does. It's essential to preserve state of all form elements, even those outside currently submitted part of form (it's unacceptable to lose newly entered (unsubmitted) text when user uploads an image). Roundtrip to server may be needed to add/remove elements within form, and decision may be based on data unavailable on client-side. -- regards, Kornel Lesinski
Re: [whatwg] attribute value normalization
On Thu, 21 Jul 2005 18:46:53 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: That conflicts with XML rules: If the attribute type is not CDATA, then the XML processor must further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character. You got two things wrong. (1) Per HTML 4 the attribute type _is_ CDATA Are you sure? HTML4 DTD defines input type as enumeration, and all sources I've found say that's not the same as CDATA. -- regards, Kornel Lesinski
Re: [whatwg] The first submit button in a form is the form's default button
On Wed, 13 Jul 2005 13:54:48 +0100, Ian Hickson [EMAIL PROTECTED] wrote: Forms often have multiple submit buttons that perform actions on form data and are not suitable as a default button (remove this element, and others like add, upload, lookup, etc.). In such cases LAST submit button is more likely to be suitable as the default submit button. Although there are forms, like PayPal login page, where neither first or last submit button is suitable as default (first is creation of new account and last is cancel). I agree. However, browsers implement what the spec currently says, so there isn't much we can do about what the default default button is. In IE and FF this can be worked around by inserting invisible button at the beginning of form to capture default submission. Opera has diffrent approach (uses button following control in which enter has been pressed), which makes workaround more difficult, but OTOH current Opera's solution is good enough. -- regards, Kornel Lesinski
Re: [whatwg] suggestion: LINK element for session termination
On Mon, 13 Jun 2005 12:38:12 +0100, Hallvord R M Steen [EMAIL PROTECTED] wrote: I suggest a new LINK rel definition: LINK rel=logout href=/logout.cgi / How about adding user's identity to this? So UA UI could show Logged in as $foo [Log out]. Is title attribute appropriate? -- regards, Kornel Lesinski
Re: [whatwg] General TCP connections API?
On Thu, 26 May 2005 21:30:18 +0100, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: To have your own connections you'd have to use other port than 80 and that may be disallowed on many restricted systems. Could you please elaborate on this. Clients that have many blocked ports on firewall - for example to block P2P inside school networks. If user navigates to the next page, browser will destroy your JS objects and close their connections. I don't really see this as a problem. A web application would be one page (with possibly other pages embedded in it). You're right. Even if connections are limited to the same host, you couldn't safely serve anything else on it. Spammers might use numerous HTML-injection techniques to send spam using other people's computers, and this may get much worse if host restriction fails. Could you please elaborate on this. Let's say there's website example.com/page.php?name=John that prints Hello John! On your website, if you create iframe with URL: example.com/page.php?name=scriptconnectPort(25).send(HELO...SPAM...SPAM);/script every visitor will send spam using example.com server. On a second thought this may be prevented by forcing some special handshake or transport protocol for custom connections... but then this feature becomes just alternative HTTP + XML RPC that only offers smaller lag for price of increased complexity and worse browser/server support. Is it worth it? -- regards, Kornel Lesinski
Re: [whatwg] A thought: a href=... method=post
On Fri, 13 May 2005 16:56:44 +0100, James Graham [EMAIL PROTECTED] wrote: That seems to be based on the belief that all things which look like links must correspond to idempotent actions. Yes, that is exactly the idea behind it. I don't think this is true and, in general, think that trying to couple the user interface to the underlying protocol is a bad idea. That is user interface which represents what protocol does. Links are not coupled with http GET method. You may link to any resource using any protocol, but following a link should not have side-effects - by design. Web applications usually don't have undo, so IMHO it should be clear that click on certain UI elements has side effects. Difference between radio buttons and checkboxes is quite clear by looks of them. There should be difference between links and buttons as well, because one _goes_ somewhere, and another _does_ something. In case with marking e-mail as read that would be element that _goes_ somewhere AND _does_ something, so I think that a might be suitable in this case. How about requiring non-idempotent links to have rel=nofollow? That might solve the google accelerator problem. -- regards, Kornel Lesinski
Re: [whatwg] A thought: a href=... method=post
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] Drag and drop in HTML5
On Wed, 04 May 2005 23:51:17 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
So there is currently no whole-element drag-and-drop API that we can
conveniently re-use. There are use cases though:
As a web developer I'd like:
- enabling/disabling dragging for each DOM element:
foo.draggable = true;
- event that asks if item can be dropped here. Dragged item should
fire events on elements it hovers (like onmouseover) and response to this
event (preventDefault?) should control if mouse pointer looks 'forbidden'
or 'normal' accordingly.
foo.addEventListener('dragtarget',function(e) {if (this.isBusy)
e.preventDefault();},false);
If it can't be an event (above example doesn't look bulletproof to me),
less convenient method like specifying if element is allowed target may be
sufficient (foo.dragTarget = true)
- 'item dropped' event fired on target element
- :drag CSS pseudo-class is nice idea. There might be also :drag-target
(:drag:target?) pseudo-class that styles elements that agreed to be drag
target.
:drag {opacity: 0.5;}
:drag-target {outline: 2px dotted red;}
There is use-case of reordering items, which means dragging items in
between other items. That seems a bit more complex, and probably needs
additional helper API.
To implement this with simple interface I've proposed, events should be
handled either by existing elements (like list items that compare their
size and position of dragged element to decide whether element should be
dropped before or after) or handled by container that would probably need
to calculate positions of it's children and create new element to show
drop target. Smooth Mac-like drag'n'drop can be implemented by animating
drop target's padding/margin. So that's quite a bit of code that's going
to be reinvented each time someone implements reordering.
--
pozdrawiam, Kornel Lesinski
Re: [whatwg] Canvas element - Keep It Simple
On Fri, 22 Apr 2005 18:55:12 +0100, Anne van Kesteren
[EMAIL PROTECTED] wrote:
As there are already implementations and implementors are not likely to
change it all back I don't think this is going to work, but if this
somehow gets through then please choose the OBJECT element instead.
I think canvas is the best solution.
object is already complex and too many ways
of defining it's contents led to poor support.
canvas doesn't belong to CSS, because CSS can't use it.
Developers would use it via object.style.canvas = 'enabled' or something
like that.
Enabling via JS IMHO doesn't work either. Just adds unneccesary code:
div id=canvas/div
script
type=text/javascriptdocument.getElementById('canvas').drawable=true/script
It has been mentioned before that UAs probably won't manage to support
drawing
on every element, so authors would limit themselves just to something basic
like static or abslutely positioned div.
canvas as element has some advantages:
It would be possible to modify prototype of HTMLCanvasElement
to add functions that are missing in some implementations or
- in case of safari - find all canvas elements and replace
them with safari-compatible ones - that would be very difficult if canvas
was enabled via CSS or JS method.
Another problem is that it would be very useful to create images
for CSS via scripting (like rounded corners, shades, patterns),
but I don't see any elegant way of joining those two...
foo {background: url(#id_of_canvas_element);}
canvas.onlyForCSS {display: none;}
--
regards, Kornel Lesinski
Re: [whatwg] Canvas element - Keep It Simple
On Sun, 24 Apr 2005 16:14:29 +0100, Jim Ley [EMAIL PROTECTED] wrote: Neither can HTML - it's always blank unless script is supported, so by that argument, Script, and only Script is the appropriate place. It needs to be in DOM. If every element could be made canvas by script, each DOM element would have to implement neccessary interface. canvas limits this support only to certain elements and lets browsers attach neccesary styling and behaviour beforehand. You've made these seem bloated, but you're ignoring the fact that the only extra code in that example is the .drawable=true - if that really is a problem, then it would be trivial to not require it and just allow drawing to start on top of any element. Drawable img is pretty easy to implement (change to internal bitmap), but drawable div might be really difficult (additional overlay of bitmap). It would be possible to modify prototype of HTMLCanvasElement to add functions that are missing in some implementations or The existence of an HTMLCanvasElement prototype is not standard currently It's in current draft, with width/height properties and getContext method. - are you suggesting that the Web Application specification should require the prototyping of these objects? I would be very much opposed to this, requiring a particular coupling to javascript is not a good idea. But such coupling is already there for every current form element. Prototypes are required by ECMA script already. -- regards, Kornel Lesinski
Re: [whatwg] Re: section and headings and other threads
On Wed, 06 Apr 2005 13:45:07 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
[Redirected to [EMAIL PROTECTED] According to the mail headers in the
message I received, you sent it to [EMAIL PROTECTED] I can't find it in
the archives of either www-style nor whatwg, though.]
Oops :)
If address applies only to the element it's in,
some duplication may be needed:
My articles on my page:
body
article
addressme!/address
/article
article
addressme!/address
/article
addressme!/address
/body
I think best would be address for=IDREFS
I don't really understand. Why would you want to give the contact
information for the inner articles if it is the same as for the section
that contains them? The inner articles are part of the body. Contact
information for the body applies to the whole body.
The article element represents a section of a page that consists of a
composition that forms an independent part of a document
I assumed that because of this independence it needs its own address
element.
How about inline aside?
For inline comments, explanations, translators notes, etc.
pPut the disc in the cd drive aside(that cup holder
thingie)/aside/p
aside is for what are typically rendered in printed media as floating
sidebars. Short inline comments are catered for by the title attribute:
pPut the disc in the span title=that cup holder thingiecd
drive/span/p
Title attribute is not immediately visible on page and requires reader to
pause
and wait for it to appear.
...or, more typically, simply by marking the comment with parentheses, as
you did in your example:
pPut the disc in the cd drive (that cup holder thingie)/p
I think good use of aside element is possiblity to 'clean up' articles
from comments:
article aside {display: none;}
This also may be useful for search engines - they could omit aside
in quoted page fragments.
That element could play role as opposite of em and strong.
--
regards, Kornel Lesinski
