[whatwg] Link-related feedback
On Wed, 28 May 2008, Martin Atkins wrote: [regarding link rel=stylesheet and .disabled] I wonder what use-case motivated that attribute that couldn't have been satisfied by merely removing the LINK element from the DOM. Or, if you wish to attack it from the other direction, why a generic solution for causing browsers to temporarily ignore *any* HTML element (a use case for which might be pop-up dialogs that are hidden at certain points) wasn't more appropriate. Also, I note that the spec as it currently stands defines disabled only as a property of the HTMLLinkElement and not as an attribute of the LINK element. I don't know if this was intentional. Of course, I could very well make the same objection about a type-specific property on a class being better implemented by creating a new class. The spec merely describes what the implementations and earlier DOM specs do and say. Finally, what is the process for contributors to the RelExtensions page to include extension attributes? They can't. Given that you obviously consider it useful for third-parties to be able to introduce new rel values without changing the HTML5 spec There have been convincing arguments made along these lines, yes. I'm not sure I would say that I think it's a good idea personally... and that you also obviously consider it useful for certain rel values to carry additional attributes, I find it likely that some of these third-parties will also find it useful to introduce additional attributes. Would you not agree? So far in ten years, we've only had one rel value that needed a new attribute. I think at that rate, we can rely on such extensions going through the normal spec extension mechanism rather than needing an expedited extension mechanism (which is what we have for rel values). link rel=icon type=image/gif; width=24, height=24 href=... This doesn't really work because we would need to add parameters to types we might not yet know. It also results in potentially complicated parsing rules, which I don't think people would get right. (See the comments I made for media queries.) Presumably this would be defined (if at all) for everything under image/, just as charset is defined for everything under text/. (In theory, at least.) Getting the relevant RFCs changed would likely be non-trivial. (Though we should probably look into it, actually, to fix text/*.) Given that (for now, at least) these type attributes would be of little use outside of HTML, could HTML not define them itself? Sure, it's a bit of a layering violation, but I would put it in the same boat as modifying MathML/SVG so that it works inside HTML: you just reference the bits of the other spec that suit you, and make your own exceptions, right? (loud objections from the MathML guys notwithstanding, of course. The MIME type RFC isn't authored by a W3C working group, so they won't find it so easy to complain!) We're not changing MathML and SVG either. As you say, it would be a layering violation. On Fri, 9 May 2008, Kornel Lesinski 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. I don't know exactly what Kornel was asking, but this seems to be a backward-compatibility concern. When given the following: link rel=icon sizes=16x16 ... / link rel=icon sizes=512x512 ... / ...current Opera will download both, which is suboptimal however you look at it. Current Firefox, though, will presumably download the 512x512 version in preference to the 16x16 one even though its icon slot is (usually) 16x16 pixels. I guess this concern would be solved (aside from Opera's behavior) if the spec were to say that a 16x16 icon, if specified, should be the last one listed for compatibility with legacy browsers. (Also, a 9.5 beta tester should probably inform Opera of that issue if they aren't already aware of it.) I think it would make sense for an authoring guide to mention this, but I don't think we need to saddle the language with this requirement forever. This isn't a huge deal really. On Wed, 28 May 2008, Kornel Lesinski wrote: 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
Re: [whatwg] Database feedback
On Wed, 26 Nov 2008, Jim Jewett wrote: I would name the question mark character aqt least once, so that it can't be mistaken for a placeholder in the spec (rather than in the SQL): Where it now says: Parse the first argument to the method (sqlStatement) as a SQL statement, with the exception that ? characters can be used in place of SQL literals in the statement. [SQL] Done. This still leaves open whether the statement has to actually be PREPAREd, and whether other parameter types or host variables are supported. I'm not sure what you mean. There are systems where you need to prepare a SQL statement before you can execute it, but I think the current wording makes clear that this system works from the strings, and does the PREPARE-ation itself as part of execution. Yeah, that's an implementation detail. On Wed, 26 Nov 2008, Aaron Boodman wrote: On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson i...@hixie.ch wrote: We could have a .writeTransaction() and a .readTransaction(), where the former always run in isolation. Any preferences? My preference is for separating read transactions from write transactions. Then the API could throw if you tried to write in a read transaction. On Wed, 3 Dec 2008, Scott Hess wrote: In SQLite the lock is upgraded as-needed, and it does cause confusion. The following can fail to get the write lock at the marked statement: BEGIN DEFERRED; SELECT x, y, z FROM t WHERE q = ?; INSERT INTO j VALUES (?, ?, ?); -- *mark* COMMIT; In SQLite BEGIN is the same as BEGIN DEFERRED. Gears changes the default for BEGIN to BEGIN IMMEDIATE, which acquires the lock right away. If a developer wants to do a read-only transaction, they can explicitly execute BEGIN DEFERRED. In any case, my point is that upgrading mid-stream seems to be a point of confusion for people. You can explain what's happening, and they will understand it, but the case comes up seldom enough that most people never internalize it. Requiring an explicit decision up front makes things clear, and doesn't absurdly widen the API. I would lean towards .transaction() and .readTransaction(), though. Acquiring the lock immediately is almost always the right thing to do. You can code a join to get consistent data from multiple tables, but you cannot code a single statement to insert data consistently into multiple tables (ignoring triggers), which is why read-only explicit transactions are rare, and write-only explicit transactions are common. I'd say that write-mostly transactions (one or two reads followed by a bunch of writes) are probably also more common than read-only transactions. On Wed, 26 Nov 2008, Jonas Sicking wrote: I'm fine with either the perf-hit solution or the .writeTransaction/.readTransaction solution. Both seems better than having writes throw under basically race conditions. If we go with the perf-hit solution we can always add the speedier .writeTransaction/.readTransaction APIs in a later version. I've introduced transaction()/readTransaction(), and made readTransaction() fail when executeSql() is called with a method that would mutate the database. On Wed, 26 Nov 2008, Chris Prince wrote: On Mon, 26 May 2008, Chris Prince wrote: // On the 1st call, this line means create a database, // and set the version string to the empty string. var db1 = window.openDatabase(foo, , , ); // On the 2nd call, the meaning has changed to // open the 'foo' database, regardless of the version string. var db2 = window.openDatabase(foo, , , ); On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson i...@hixie.ch wrote: Yeah, that's a bit confusing. Not sure what to do about it. Two ideas: * Perhaps use a different value to mean open any version, if one exists. Using 'null' seems like an obvious candidate. * Alternately, don't allow the empty string as a valid version string. Only use the empty string to mean open existing. Well the thing is that if the database doesn't exist, I still want the open the database regardless of its version case to actually open (and create) the database. The problem is what to use as the version string in that case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Resolving URLs
On Fri, 27 Jun 2008, Adam Barth wrote: In http://www.whatwg.org/specs/web-apps/current-work/#resolving, the spec says: If the URL to be resolved was passed to an API The base URL is the document base URL of the script's script document context. I believe browsers differ on this point. When resolving a URL received from a script, there are three likely sources of a base URL: 1) The script's script document context (i.e., the document of the window object lexically in scope). 2) The document of the window object dynamically in scope. 3) The document to which the API belongs. I'm working on a test suite to reverse engineer the behavior of current browsers and will report my findings. The spec has changed now, but it is still based on a feature of the script right now. I would be interested in hearing the results of your research. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Scripted querying of video capabilities
FWIW, in nightly Gecko builds we have an implementation of canPlayType per spec. It parses the codecs parameter of the provided MIME type, so we can answer no, maybe or probably depending on what's in the type. E.g.: http://mxr.mozilla.org/mozilla-central/source/content/media/video/test/can_play_type_ogg.js Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] Notifications API removed
I've commented out the Notifications API, since there was little interest in it, and what little interest there was was in the form of requests for a rather complete overhaul (changing from strings to arbitary documents). Since notifications are mostly independent of HTML anyway, I encourage people who are interested in this feature to define it in an orthogonal specification, e.g. in the W3C Web Apps working group. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] number-related feedback
On Fri, 22 Aug 2008, Shannon wrote: I was going to suggest the spec define unsigned integers as a value between 1 and MAX_INT inclusive when I realised the spec doesn't define the range of integer values at all. Is this deliberate? Yes. The range is likely to differ based on the platform used -- today's 32 bit systems will likely have different ranges than next decade's 128 bit systems. Either way I would recommend making a decision on minimum and maximum integer values an using them consistently. If not I can imagine the rapid adoption of 64-bit systems will cause unexpected errors when the same code is run on older 32-bit systems. There are valid arguments for letting each system use its native integer but if this is the case then perhaps the spec should require MIN_INT and MAX_INT be made available as constants. ECMAScript does define a range, and the limits of that range are exposed to scripts. Are there cases where there are non-script limits that would benefit from being exposed? Use cases would be helpful here. Also the spec interchanges the terms non-negative integer, positive integer and unsigned integer. I suggest defining one of these clearly and then using it everywhere. non-negative integer is used to mean zero-or-more. I got rid of all cases of positive integers I could find. I changed the heading of the section on non-negative integers to say non-negative instead of unsigned but now the sections are inconsistently named, which may annoy me enough that I'll change it back at some point. This is a very minor point but is it necessary to say valid integer. Given that there appears to be no defined min/max range when is something both an integer and at the same time invalid? Isn't an invalid integer a string? A valid integer is a string also. I don't understand what you mean. Finally I wasn't aware Javascript made a distinction between signed and unsigned integers. Is the distinction really necessary? Can we just make everything signed integers and consistently call the full range integer and the positive range integer greater than 0? JavaScript doesn't make the distinction, but other languages do, and WebIDL defines behavior for unsigned integers that is different from signed integers. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
