Re: [whatwg] CSS2 system colors in legacy color values
On Aug 3, 2010, at 6:33 PM, Ian Hickson wrote: We're talking about body bgcolor=Highlight here, not about the colour of selected text. I see. And I can reproduce the bug you’re talking about. I’ll probably fix it, but point taken. -- Darin
Re: [whatwg] Race condition in media load algorithm
On Tue, 03 Aug 2010 17:40:33 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 8/3/10 4:27 AM, Philip Jägenstedt wrote: For the record, here's how I interpreted await a stable state: The only state that is not stable is a running script. I don't think that's true; for example you could be in an unstable state if you're in the middle of the parser inserting some nodes into the DOM. If the parser running in considered an unstable state, then we would have to wait until the whole document has finished parsing before running the resource selection algorithm. Thus, video would be unnecessarily delayed in a way that img isn't. The spec is certainly written in a way that makes good sense when triggering the resource selection algorithm when the parser first sets a src attribute or appends a child source element and then waiting in NETWORK_NO_SOURCE for more source elements. If this isn't the intention, I have really completely misunderstood what the spec is trying to do. Whatever the language used, I suggest letting the parser trigger the resource selection algorithm synchronously. Therefore, when reaching that step, if the resource selection algorithm was triggered by a script, wait until that script has finished and then continue. Per spec as currently written, this will give the wrong behavior. For example, if the script in question calls showModalDialog, this is supposed to interrupt the script task and spin the event loop, and so your synchronous section would need to run while the modal dialog is up. It doesn't sound like your implementation does that. That could be, but is this behavior actually useful for anything? It's certainly simpler to implement and more predictable for authors to always wait until the current script has finished executing. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Proposal for Web Storage expiration
On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. J
Re: [whatwg] Race condition in media load algorithm
On 8/4/10 4:29 AM, Philip Jägenstedt wrote: That could be, but is this behavior actually useful for anything? It's certainly simpler to implement and more predictable for authors to always wait until the current script has finished executing. 1) That requires defining current script. 2) Who said it will ever finish executing? -Boris
Re: [whatwg] HTML resource packages
Justin Lebar: We at Mozilla are hoping to ship HTML resource packages in Firefox 4, http://people.mozilla.org/~jlebar/respkg/ | html packages='[pkg1.zip img1.png script.js styles/style.css] |[static/pkg2.zip]' A page indicates in its html element that it uses one or more resource packages (…). Why do you want to put this on the HTML level (exclusively), not the HTTP level? As far as I undestand it, authors would usually put stylesheets, scripts and decorative images, but not HTML files into a resource package. These are usually common to several pages or the entire site or domain. Images might be referenced from within HTML or CSS files. Why did you decide against link rel=resource-package href=pkg1.zip#files='img1.png,…'/ or something like that? (The hash part is just guesswork.) * Argument: What about incremental rendering? If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough.
Re: [whatwg] HTML resource packages
On 4 August 2010 20:08, Christoph Päper christoph.pae...@crissov.de wrote: * Argument: What about incremental rendering? If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough. ZIP files are progressively renderable, dependant on file order.
Re: [whatwg] HTML resource packages
On Wed, Aug 4, 2010 at 12:11 PM, James May wha...@fowlsmurf.net wrote: On 4 August 2010 20:08, Christoph Päper christoph.pae...@crissov.de wrote: * Argument: What about incremental rendering? If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough. ZIP files are progressively renderable, dependant on file order. In my experience gzip compression is blocking browser rendering until the compressed file has been received completely. I believe this is the reason we should not compress the HTML source, just its external binary components. I don't think the browser can separately decompress each block of a chunked transfer as it arrives, am I wrong ? Diego Perini
Re: [whatwg] Race condition in media load algorithm
On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 8/4/10 4:29 AM, Philip Jägenstedt wrote: That could be, but is this behavior actually useful for anything? It's certainly simpler to implement and more predictable for authors to always wait until the current script has finished executing. 1) That requires defining current script. OK, but that's just a spec problem. It's trivial in implementation because when the resource selection algorithm was is triggered by a script, you can just pass along a reference to that very script. 2) Who said it will ever finish executing? If it doesn't, just don't ever continue with the synchronous section. Is there any valid case for a script never finishing? It would block all event handlers from running too, so in any case it's a broken page. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML resource packages
On Wed, Aug 4, 2010 at 1:31 AM, Justin Lebar justin.le...@gmail.com wrote: We at Mozilla are hoping to ship HTML resource packages in Firefox 4, and we wanted to get the WhatWG's feedback on the feature. For the impatient, the spec is here: http://people.mozilla.org/~jlebar/respkg/ It seems a bit surprising that [pkg.zip img1.png img2.png] provides more files than [pkg.zip img1.png] but *fewer* files than [pkg.zip] (which includes all files). I can imagine people would write code like: print html packages='[cached-image-thumbnails.zip . (join , @thumbnails_which_are_not_out_of_date) . ]'; (intending the package to be updated infrequently, and used only for images that haven't been modified since the last package update), and they would get completely the wrong behaviour when the list is empty. So maybe [pkg.zip] should mean no files (vs pkg.zip which still means all files). Filenames in zips are byte-strings, not Unicode-character-strings. What should happen with non-ASCII in the zip's list of contents? People will use standard zip programs and frequently end up with various random character encodings in their file - would browsers guess or decode as CP437 or decode as UTF-8 or fail? would they look at the zip header's language encoding flag? etc. What happens if the document contains multiple html elements (not all the root element)? (e.g. if it's XHTML, or the elements are added by scripts). The packages spec seems to assume there is only ever one. The note at the end of 4.1 seems to be about avoiding problems like http://evil.com/ saying: html packages=eviloverride.zip !-- gets downloaded from evil.com -- base href=http://bank.com/; img src=http://bank.com/logo.png; !-- this shouldn't be allowed to come from the .zip -- Why is this particular example an important problem? If the attacker wants to insert their own files into their own pages, they can just do it directly without using packages. Since this is (I assume) only used for resources like images and scripts and stylesheets, and not for a hrefs or iframe hrefs, I don't see how it would let the attacker circumvent any same-origin restrictions or do anything else dangerous. The opposite way seems more dangerous, where evil.com says: html packages=http://evil.com/redirect.cgi?http://secret-bank-intranet-server/packages.zip; img src=http://evil.com/logo.png; !-- now use canvas to read the pixel data of the secret logo, since it was loaded from the evil.com origin -- Is anything stopping that? In 4.3 step 2: What is pkg-url initialised to? (The package href of p?) -- Philip Taylor exc...@gmail.com
Re: [whatwg] HTML resource packages
On 4 Aug 2010, at 11:46, Diego Perini wrote: * Argument: What about incremental rendering? If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough. ZIP files are progressively renderable, dependant on file order. In my experience gzip compression is blocking browser rendering until the compressed file has been received completely. I believe this is the reason we should not compress the HTML source, just its external binary components. I don't think the browser can separately decompress each block of a chunked transfer as it arrives, am I wrong ? You are wrong. gzip compression is streamable and browsers can uncompress parts of gzipped file as it is downloaded. gzip only needs to buffer some data before returning uncompressed chunk, but it's only few KB. Chunks of gzipped data don't have to align with chunked HTTP encoding (those are independent layers). -- regards, Kornel
[whatwg] [br] element should not be a line break
Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though. Currently, I'm writing a book on web programming and I stumbled over the specification of the br element for HTML5. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element In the past, there has been a lot discussion about not using br just to insert line breaks everywhere. I'm fully aware that we have lots of elements that are often a better fit and that, of course, line breaks can be achieved by blocking inline elements. What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. In addition, the appropriate uses (poems, addresses) and examples currently given are not convincing. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address Or just: address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address Regarding poems, line breaks have conventionally been used in Western literature to aid in manifesting the rhythm. And there surely are many poems that use formatting for artistic effect. But I think it would be hard to say that *line* breaks are an inherent part of poems per se. I'd say that breaks are important means to determine structure, but line breaks are just one of many possible manifestations of such breaks. Just like in a musical score where the bar is present in sheet music but not in the actual music being played. Interestingly, the examples given for where not to use br look like great examples to actually use a break element (not necessarily a line break). First example: pa ...34 comments./abr a ...Add a comment./a/p There are two separate pieces of text that belong together (they are both related to comments). So using one paragraph to group them is fine. But they can benefit from a separation that is a bit stronger than just punctuation since one of them is purely informational and the other is a call to action. This is where a break element is perfect. One designer might want a line break. So he should be able to set a line break property on that break. Another designer doesn't like line breaks. So let her set the break to be generated as a green, medium-sized dot. Second example: plabelName: input name=name/labelbr labelAddress: input name=address/label/p Although I also prefer the version without the br element, I must say that a form is the one element where presentational markup does make sense. By its very nature a form has an explicit design, otherwise it would be called free-form. Granted, in web design there usually isn't and probably shouldn't be such a strong form character as in paper-based forms. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property. I would love to hear your thoughts. -- Thomas Koetter
Re: [whatwg] [br] element should not be a line break
Hi.. I too am new to this discussion, but I thought I'd share my thoughts. Personally, I agree with you on the topic. I would dispute the use of the address tag in all circumstances, as if I remember correctly this is for marking up contact information for an author of the page? But yes, I agree. For example we should be able to disable the line-breaks' presentational effect easily through the use of a stylesheet (or indeed enable it). On 4 August 2010 13:56, Thomas Koetter thomas.koet...@id-script.de wrote: Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though. Currently, I'm writing a book on web programming and I stumbled over the specification of the br element for HTML5. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element In the past, there has been a lot discussion about not using br just to insert line breaks everywhere. I'm fully aware that we have lots of elements that are often a better fit and that, of course, line breaks can be achieved by blocking inline elements. What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. In addition, the appropriate uses (poems, addresses) and examples currently given are not convincing. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address Or just: address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address Regarding poems, line breaks have conventionally been used in Western literature to aid in manifesting the rhythm. And there surely are many poems that use formatting for artistic effect. But I think it would be hard to say that *line* breaks are an inherent part of poems per se. I'd say that breaks are important means to determine structure, but line breaks are just one of many possible manifestations of such breaks. Just like in a musical score where the bar is present in sheet music but not in the actual music being played. Interestingly, the examples given for where not to use br look like great examples to actually use a break element (not necessarily a line break). First example: pa ...34 comments./abr a ...Add a comment./a/p There are two separate pieces of text that belong together (they are both related to comments). So using one paragraph to group them is fine. But they can benefit from a separation that is a bit stronger than just punctuation since one of them is purely informational and the other is a call to action. This is where a break element is perfect. One designer might want a line break. So he should be able to set a line break property on that break. Another designer doesn't like line breaks. So let her set the break to be generated as a green, medium-sized dot. Second example: plabelName: input name=name/labelbr labelAddress: input name=address/label/p Although I also prefer the version without the br element, I must say that a form is the one element where presentational markup does make sense. By its very nature a form has an explicit design, otherwise it would be called free-form. Granted, in web design there usually isn't and probably shouldn't be such a strong form character as in paper-based forms. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property. I would love to hear your thoughts. -- Thomas Koetter
Re: [whatwg] HTML resource packages
People should probably consider reading the Web Apps Widgets working group archives (they're public) about widget packaging. There are long discussions about zip and gzip, etc. http://www.w3.org/TR/widgets/#zip-archive Especially http://www.w3.org/TR/widgets/#character-sets covers character sets. As for zip streaming / gzip streaming... Officially Zip technically has ways to construct archives which are painful. In practice I don't think that's a real problem (beyond that user agents would need to ensure to fail any packages which abuse those features). People tend to come late to the game and say why didn't you use gzip. The general short answer is that gzip doesn't cover a file container format at all, and browsers tend to already support zip. So the cost of using zip is negligible whereas adding something else which is messy (e.g. tar, star, pax) is painful. And if you think that tar is well specified, I have a bridge I'd like to sell you.
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 3:56 PM, Thomas Koetter thomas.koet...@id-script.de wrote: Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though. If you haven't taken the time to read the FAQ in its entirety, I'd suggest that you take the time to do so. http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. Changing how an existing entity from HTML1..4 works would result in browsers which do not properly render content from HTML1..4 which is not acceptable
Re: [whatwg] [canvas] getContext multiple contexts
On Aug 3, 2010, at 3:41 PM, Ian Hickson wrote: On Tue, 3 Aug 2010, Chris Marrin wrote: On Aug 2, 2010, at 3:16 PM, Ian Hickson wrote: On Thu, 29 Apr 2010, Vladimir Vukicevic wrote: A while ago questions came up in the WebGL WG about using a canvas with multiple rendering contexts, and synchronization issues that arise there. Here's our suggested change to getContext. This seems overly complex. I've gone for a somewhat simpler approach, which basically makes canvas fail getContext() if you call it with a context that isn't compatible with the last one that was used, as defined by a registry of contexts types. Currently, only '2d' and '3d' are defined in this registry, and they are not defined as compatible. '3d'? We're calling it 'webgl'. Is there another 3D context registered somewhere? Sorry, typo in the e-mail. The spec correctly refers to a webgl context. (I have to say, I'd rather we called it 3d. I hate it when we embed marketing names into the platform.) I generally agree. For me, I consider WebGL to be a clarifying name like HTML, rather than a marketing name. [arguments on getContext] We feel it's more appropriate on the getContext() call because it involves creation of the resources for the context. If it were a separate call, you'd need to defer creation of those resources until the attribute call is made or create them as needed. This not only involves overhead in every call, but it requires you to provide specific rules on which calls cause automatic resource creation. Making it a parameter to getContext simplifies the definition. And it seems this would be a useful parameter for many types of contexts, even the 2D context as Vlad pointed out. What happens if you call getContext with the same contextID but different attributes? Good question. It's addressed in https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#2.1. It says that subsequent calls ignore the attributes. There is a getContextAttributes call on the context to return what attributes were actually set. - ~Chris cmar...@apple.com
[whatwg] Channel Messaging (is it broadcast allowed?)
Hi, I'm playing with Channel Messaging in Opera 10.60. I'm trying to connect to the same port more than one browsing context in order to do message broadcasting. It seems it is not working. Are message ports intended to be used for broadcasting i.e. more than one browsing context listening to incoming messages? best
Re: [whatwg] [br] element should not be a line break
-Original Message- From: timeless.b...@gmail.com [mailto:timeless.b...@gmail.com] On Behalf Of timeless Sent: Wednesday, August 04, 2010 5:07 PM If you haven't taken the time to read the FAQ in its entirety, I'd suggest that you take the time to do so. http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. Changing how an existing entity from HTML1..4 works would result in browsers which do not properly render content from HTML1..4 which is not acceptable Thanks for the hint about the FAQ. Regarding the br element I believe that my suggestion does just that. It supports existing content by defaulting br to be displayed as a line break. But going forward br would be considered a minor logical break inside a paragraph. Presentation could be changed from the default line break to some generated content. Now seems to be a good time to implement such a change in the semantics. Correct me if I'm wrong, but hr went through a very similar change.
Re: [whatwg] Race condition in media load algorithm
On 8/4/10 6:56 AM, Philip Jägenstedt wrote: On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 8/4/10 4:29 AM, Philip Jägenstedt wrote: That could be, but is this behavior actually useful for anything? It's certainly simpler to implement and more predictable for authors to always wait until the current script has finished executing. 1) That requires defining current script. OK, but that's just a spec problem. It's trivial in implementation because when the resource selection algorithm was is triggered by a script, you can just pass along a reference to that very script. It's not, in fact, trivial in implementation. You're making assumptions about how implementations work that don't seem warranted (e.g. the concept of reference to that very script is not well-defined in some implementations). In particular, what you're proposing is not at all trivial in Gecko. 2) Who said it will ever finish executing? If it doesn't, just don't ever continue with the synchronous section. I don't think that's reasonable. Is there any valid case for a script never finishing? Yes, it could showModalDialog and the user could spend several hours interacting with it. It would block all event handlers from running too I believe this is false in the case of showModalDialog. -Boris
Re: [whatwg] Proposal for Web Storage expiration
On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. I'm definitely for expiration of localStorage values. Though I think it also makes sense to do for IndexedDB. Especially if it can be done on a per-objectStore basis as that makes it very low overhead. / Jonas
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
Sorry for the lagged response,
On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt oli...@apple.com wrote:
On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
The e-mails quoted below consist of the salient points of this thread:
On Fri, 23 Apr 2010, David Bruant wrote:
Make that HTMLCollection (and all HTML*Collection, as a consequence of
inheritence of HTMLCollection) inherit from the ECMAScript Array
prototype. This way, it will make available all Array extra methods
(forEach, map, filter...) added in ECMAScript5 (and next versions which
should go in the same direction).
As far as I know, adding this won't break any existing code. The
semantics of a Collection and the way it is used is very close from
ECMAScript Arrays. I don't think that the notion of live object and
ECMAScript Array are incompatible either. Once again, I am talking about
ECMAScript binding. I have no intention to touch the HTMLCollection
interface or other languages bindings.
On Sun, 25 Apr 2010, J Z wrote:
If HTMLCollection was inheriting from Array, and methods like `forEach`,
`map`, etc. were to operate on a live object, there would definitely be
undesired consequences. We can see this in, say, Firefox (which allows to
set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
HTMLCollection.prototype.__proto__ = Array.prototype;
document.getElementsByTagName('div').forEach(function(el) {
el.parentNode.removeChild(el); // doesn't work as expected
});
// turning live collection into static array fixes this
Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
el.parentNode.removeChild(el);
});
On Sat, 24 Apr 2010, David Bruant wrote:
I think I can take your point as a pro more than a con, because in
ES5, right before the definition of each array extra method, a paragraph
like the following can be found :
The range of elements processed by forEach is set before the first call
to callbackfn. Elements which are appended to the array after the call
to forEach begins will not be visited by callbackfn. If existing
elements of the array are changed, their value as passed to callback
will be the value at the time forEach visits them; elements that are
deleted after the call to forEach begins and before being visited are
not visited.
This point is confirmed by every algorithm where the length is saved
once for all before the loop and not got from the .length property each
time.
On Mon, 26 Apr 2010, Erik Arvidsson wrote:
On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
Le 25/04/2010 00:39, J Z a écrit :
I have thought a lot about weirdnesses that people could think about
like trying to assign a value to the HTMLCollection (divs[14] =
myOtherDiv), but once again, it wouldn't be more allowed than it
currently is (I have no idea of what happens today, but if an error
is thrown in a for-loop, it should throw an error as well in a call
within a forEach).
How would destructive methods like `push` or `sort` behave? Would
`document.body.childNodes.push(document.createTextNode('foo'))` append
text node to a body element? Or would it be a noop?
That is actually a very good point. It think that the behavior should
be exactly the same as an equivalent without array methods. (this
point of my proposal would need to be made completly explicit for each
method)
One way to solve this could be to split Array into two interfaces. One
to be used with immutable array like objects and one to use to mutate
objects. Then we could apply the immutable array like interface to
NodeList and its related interfaces. The benefit of doing that is that
NodeList.prototype.push would be undefined instead of failing when
called.
On Mon, 26 Apr 2010, David Flanagan wrote:
Rather that trying to make DOM collections feel like arrays, how about
just giving them a toArray() method? This makes it clear that a
collection is not an array, but clearly defines a way to obtain an
array. Clever implementors might even be able to optimize common
uses-cases using some kind of copy-on-write strategy so that toArray()
doesn't involve memory allocation and copying.
Of course, trying to teach programmers when they ought to call toArray()
and when it is not necessary is another matter. Perhaps calling the
method snapshot() and focusing on the live vs. static distinction
instead of the fake array vs. true array distinction would invite less
misuse.
Or we can just leave the DOM as it is and get used to calling the
equivalent of Prototype's $A() function.
Before changing something this substantial, I'd like to have implementor
feedback regarding what the best way to address this is:
- somehow make HTMLCollections and NodeLists inherit from Array?
- define a bunch of feature on HTMLCollections and NodeLists so that
they're like
Re: [whatwg] Channel Messaging (is it broadcast allowed?)
On Wed, 4 Aug 2010, JOSE MANUEL CANTERA FONSECA wrote: I'm playing with Channel Messaging in Opera 10.60. I'm trying to connect to the same port more than one browsing context in order to do message broadcasting. It seems it is not working. Are message ports intended to be used for broadcasting i.e. more than one browsing context listening to incoming messages? More than one browsing context can listen to a specific MessagePort object, but if you clone the MessagePort object, the original one becomes orphaned and stops receiving messages. If you would like more help, I recommend sending a link to the page in question to the h...@whatwg.org mailing list: http://www.whatwg.org/mailing-list#help HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Content-Disposition property for a tags
On Mon, 02 Aug 2010, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich mkozakew...@icosidodecahedron.com wrote: I see where you're coming from, but we try not to force users to do things. Let's say you have an image editor, written using canvas and whatnot. You want to have similar UI to native image editors, and that includes a Save button (probably adorned with a little picture of a 3.5 floppy, which is amusing when you think about it). Clicking the Save button should pop up a dialog like in a native app, asking you where to save it. Currently this can be done, but you have to send a request to the server and get a Content-Disposition: attachment response. Probably you have to do it in a hidden iframe so it doesn't navigate the whole page, etc. The request is for some feature to do this without the rigamarole. OK, lets assume this is a worthy use case for a moment (it propably is). How do we know that a entity body (in HTTP parlance) should be saved to permament storage rather than presented to the user? A) Per resource metadata: Some resource is inherently insuitable for immediate presentation. Metadata regarding this can be provided by e.g. the Content-Disposation header of RFC 2076 (MIME). B) By media type: A UA may decide that a resources of certain media subtype cannot be immediately processed or presented to the user. Think application/octet-stream, executables and likely all subtypes not present in mailcap (or equivalent). C) Context: Due to the context of the link, such as per link metadata. The straightforward solution is registering a JavaScript callback to the click event on the relevant A element. This though is highly problematic as the click event isn't always fired when a link is activated (thus possibly resulting in normal navigation to the destination), UAs currently don't restyle As with listeners on click (nor any elements with attached listeners). A (or AREA) with @action, @method or @rel~=save would allow easy styling with CSS and ignoring. If you don't agree that this use-case is worth adding the feature for, do you think that: 1) The status quo is fine: you should have to send a request to the server to implement a Save button. Offline image-editing apps don't matter. Probably not a popular attitude here. 2) You (the app author) shouldn't even be able to do that. You should have to say Right-click and choose 'Save As'. Except that of course this is less convenient for the user, it takes up more space in the UI, the option might not be named the same thing in all browsers, apps might want to make right-click do something else so that context menus don't work, there are plenty of platforms (like phones) where right click doesn't even make sense, and in general the web platform makes no UI guarantees at all. So then we get multipage guides explaining how to do it in a handful of popular browsers, with images and step-by-step instructions like http://www.wikihow.com/Clear-Your-Browser's-Cache, and unpopular browser users get to figure it out themselves. IMO image-filled step-by-step guides should be replaced by scripts (runnable by lusers and readable by techies). But that's another topic. 3) Something else? All in all, this seems like a very straightforward, useful thing to ask for. Yes, users can do it through browser UI, but that doesn't permit authors to present it in a consistent way, draw the user's attention to it, put it where the user will expect it in context, etc. It's very similar to print(): of course the user can just hit Ctrl-P, but some people are used to clicking Print buttons and will be puzzled and unhappy if they don't find one. If the browsers UI doesn't have a Print button where the user expects one to be the UI is broken, not the document to be printed. Not everyone will try to think of alternative ways to perform a task when their initial expectation fails. That's the point where a lot of people give up, or call their techy friends or relatives for help. Many people use computers by rote, and don't know what to do when the usual incantation fails. Even for those of us who know better, it's can be more convenient if the application has more control, so they we don't *have* to manually click through menus when the app can do it for us. True. That's why web pages should provide lots of semantic metadata to applications that may use that data to make informed decisions. I propose the method attribute on link, a and area that MUST contain a case insensitive space-seperated list of methods. A list of valid methods should be obtainable from the WHATWG wiki. Note in particular that methods are not limited to HTTP methods and neet not alter the retrieval or submission of resources, though they most certainly can. Valid
Re: [whatwg] [br] element should not be a line break
data:text/html,%3Cstyle%3Ebr%20,%20b%20{display:inline;%20content:%22x%22}b:after,br:after{content:%22%20|%20%22}%20%3C/style%3Ea%3Cbr%3Eb%3Cb%3E%3C/b%3Ec
So, in Safari, the above actually lets me replace br w/ whatever I like.
bz indicates that I can't do that in Gecko because br is a replaced something.
Re: [whatwg] Questions about the progress element
On Tue, Aug 3, 2010 at 6:06 PM, Ian Hickson i...@hixie.ch wrote: If it was up to me we'd just have all the numeric types be infinite precision in the spec and have the UAs compete on how good a tradeoff they can offer between precision and performance. :-) That sounds like an interoperability nightmare. You'd get all sorts of edge cases where x/y == z tests true or false depending on how much precision the implementation uses. / Jonas
Re: [whatwg] HTML resource packages
Brett Zamir bret...@yahoo.com wrote: 1) I think it would be nice to see explicit confirmation in the spec that this works with offline caching. Yes. I'll do that. 2) Could data files such as .txt, .json, or .xml files be used as part of such a package as well? 3) Can XMLHttpRequest be made to reference such files and get them from the cache, and if so, when referencing only a zip in the packages attribute, can XMLHttpRequest access files in the zip not spelled out by a tag like link/? I think this would be quite powerful/avoid duplication, even if it adds functionality (like other HTML5 features) which would not be available to older browsers. This is tricky. The problem is: If you have an img on a page which might be able to be served from a resource package, we'll block the download of the image until can either serve the request from a resource package or can be sure that no package contains the image. I can imagine this behavior being confusing with XMLHttpRequests. On the other hand, it could certainly be powerful when used correctly. I think the natural thing is go ahead and treat things requested by an XMLHttpRequest the same as anything else on a page and retrieve them from packages as possible. If you really don't want your XMLHttpRequest to block on a resource package, you can always use a POST. But I need to investigate more to determine whether this makes sense. 4) Could such a protocol also be made to accommodate profiles of packages, e.g., by a namespace being allowable somewhere for each package? This sounds way outside the scope of what we're trying to do with resource packages. I'm all for designing for the future, but I don't think we want to introduce the complexity even of these namespaces unless we intend to use them immediately. Maciej Stachowiak m...@apple.com wrote: Have you done any performance testing of this feature, and if so can you share any of that data? There's a document (PDF) with some rough performance numbers in the bug: https://bugzilla.mozilla.org/attachment.cgi?id=455820 Although the results are preliminary, I think doing much more than this on a simulated network for a test page might be going a bit overboard. Results from real pages over real networks would be much more meaningful at this point. Separately, I am curious to hear how http headers are handled; it's a TODO in the spec, and what the TODO says seems poor for the Content-Type header in particular. It would make it hard to use package resources in any context that looks at the MIME type rather than always sniffing. Any thoughts on this? The intent is for UAs to sniff the content-type of anything coming from a resource package, so I think that TODO needs to be turned on its head: The UA shouldn't apply any of the response headers from the resource package to its elements. Christoph Päper christoph.pae...@crissov.de wrote: A page indicates in its html element that it uses one or more resource packages (…). Why do you want to put this on the HTML level (exclusively), not the HTTP level? ... Images might be referenced from within HTML or CSS files. If you reference an image from a CSS file and include that CSS file in an HTML file which uses resource packages, the image can be loaded from the resource package. Why did you decide against link rel=resource-package href=pkg1.zip#files='img1.png,…'/ or something like that? (The hash part is just guesswork.) We actually originally spec'ed resource packages with the link tag, but we encountered some difficulties with this. For example, it led to confusing behavior when a resource package was defined after a link rel='javascript'. Do we load the script from the network, or do we wait until we've received the whole head before loading any scripts? Resource packages as a link also interacted poorly with Mozilla's speculative parsing algorithm, which tries to download resources before we run the page's scripts. We probably could have come up with semantics which didn't run into problems with our own speculative parsing implementation, but we realized it would be difficult to spec it in such a way that we didn't make things very difficult for *someone*. * Argument: What about incremental rendering? The spec (and our implementation in Firefox) cares deeply about incremental rendering. Although the zip format isn't strictly suitable for incremental extraction, I defined alternate semantics in the spec which should work. Zip is better than tar-gz for this kind of thing for two reasons: * Zip file headers are uncompressed, so you don't have to extract the whole file in order to tell what's inside. * Entries in a zip file are individually compressed. Although this might cause you to compress less effectively, you can compress all your files ahead of time and construct a zip file on the fly pretty very cheaply. Philip Taylor excors+wha...@gmail.com wrote: It seems a bit surprising that
Re: [whatwg] entry script
On Sun, 30 May 2010, Perry Smith wrote: I don't see how entry script is set, when it is set, or what it is set to. Initially, there is no entry script. [1] Can someone help me out? On Wed, 2 Jun 2010, Simon Pieters wrote: The spec should probably make this clearer at the definition of 'entry script'. I've added a link to the algorithm that modifies the value of this state. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] the HTML-to-Atom mapping definition
On Wed, 2 Jun 2010, Julian Reschke wrote: Various problems have been reported with respect to the mapping [...] Please consider them raised (and still open) as per the WHATWG issue tracking rules. http://www.w3.org/Bugs/Public/show_bug.cgi?id=7806 This seems to have already been resolved (see comment 23). http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546 There is already a note to this effect below the algorithm. http://www.w3.org/html/wg/tracker/issues/86 It's unclear what needs changing for this. On Sat, 5 Jun 2010, Julian Reschke wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7545 It's unclear how to support this. We could use the sizes= attribute with rel=icon, or reintroduce the reliance on microdata vocabularies, but in both cases it seems better to wait for evidence that those mechanisms are beign adopted by authors before relying on them for this feature. On Fri, 11 Jun 2010, Julian Reschke wrote: http://www.xn--8ws00zhy3a.com/blog/2010/06/html5-atom-gone-wrong I've fixed the atom:link issue and changed xml to xhtml. I couldn't work out what the other complaints were about. If there are other problems, please raise them on the mailing list in a clear fashion and I'd be glad to update the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML resource packages
On Wed, Aug 4, 2010 at 9:01 PM, Justin Lebar justin.le...@gmail.com wrote: What happens if the document contains multiple html elements (not all the root element)? (e.g. if it's XHTML, or the elements are added by scripts). The packages spec seems to assume there is only ever one. The packages attribute should work like the manifest attribute currently works. I don't see language in the cache manifest section of HTML5 (6.6) specifying what happens when there are multiple html elements, so I hope I don't need to specify this either. :) http://whatwg.org/html#attr-html-manifest says: The manifest attribute only has an effect during the early stages of document load. Changing the attribute dynamically thus has no effect (and thus, no DOM API is provided for this attribute). Its effect is triggered from http://whatwg.org/html#parser-appcache (html token in the before html insertion mode) or from http://whatwg.org/html#read-xml , so it will only ever run for the root html element of the document. The packages attribute is defined as running Whenever the packages attribute is changed (including when the document is first loaded, if its html element has a packages attribute), so it's not the same. If you do want it to work the same then you'll need to hook into the parser and ignore dynamic updates. -- Philip Taylor exc...@gmail.com
Re: [whatwg] Why there is no wrap=off, intentional or forgotten?
On Wed, 2 Jun 2010, Old�ich Vete�n�k wrote:
I'm missing the wrap=off value for textarea wrap attribute; is there
any particular reason why this is not part of HTML5? Currently the only
values mentioned are soft and hard:
http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap
What would off mean? (In particular, how would it be different from
soft?)
However, I'd like to use wrap=off because I don't want the lines to wrap.
They don't wrap (in the submission, that is) with wrap=soft either. Do you
mean in the presentation? If so, that's a CSS issue.
There is also no mention in the spec about wrap=virtual and wrap=physical back
from the days.
http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html
Are they needed for interoperability with existing content? If not, then
it's not clear what the spec would say about them.
On Wed, 2 Jun 2010, Boris Zbarsky wrote:
On 6/2/10 10:10 AM, Lachlan Hunt wrote:
In theory, you can achieve the same effect by using CSS.
textarea { white-space: nowrap; }
This works fine in Opera, WebKit and IE. Doesn't work in Gecko though.
If you think that the above style should do something to textarea,
then the HTML spec needs to explicitly say so, since it's what defines
how the inside of a textarea is rendered, not CSS per se.
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML resource packages
If you do want it to work the same then you'll need to hook into the parser and ignore dynamic updates. Indeed. And since I explicitly *do* want dynamic updates, it'll need to change. Thanks. On Wed, Aug 4, 2010 at 1:32 PM, Philip Taylor excors+wha...@gmail.com wrote: On Wed, Aug 4, 2010 at 9:01 PM, Justin Lebar justin.le...@gmail.com wrote: What happens if the document contains multiple html elements (not all the root element)? (e.g. if it's XHTML, or the elements are added by scripts). The packages spec seems to assume there is only ever one. The packages attribute should work like the manifest attribute currently works. I don't see language in the cache manifest section of HTML5 (6.6) specifying what happens when there are multiple html elements, so I hope I don't need to specify this either. :) http://whatwg.org/html#attr-html-manifest says: The manifest attribute only has an effect during the early stages of document load. Changing the attribute dynamically thus has no effect (and thus, no DOM API is provided for this attribute). Its effect is triggered from http://whatwg.org/html#parser-appcache (html token in the before html insertion mode) or from http://whatwg.org/html#read-xml , so it will only ever run for the root html element of the document. The packages attribute is defined as running Whenever the packages attribute is changed (including when the document is first loaded, if its html element has a packages attribute), so it's not the same. If you do want it to work the same then you'll need to hook into the parser and ignore dynamic updates. -- Philip Taylor exc...@gmail.com
Re: [whatwg] Content-Disposition property for a tags
On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius svartma...@gmail.com wrote: A) Per resource metadata: Some resource is inherently insuitable for immediate presentation. Metadata regarding this can be provided by e.g. the Content-Disposation header of RFC 2076 (MIME). Not all resources have a place to put such metadata, and different resource types will require the metadata to be in different formats, and it shouldn't stick around if the user downloads and then uploads it someplace else, so I don't think this is suitable. B) By media type: A UA may decide that a resources of certain media subtype cannot be immediately processed or presented to the user. Think application/octet-stream, executables and likely all subtypes not present in mailcap (or equivalent). This doesn't address the use-case at all. Images can be immediately processed and presented to the user. C) Context: Due to the context of the link, such as per link metadata. The straightforward solution is registering a JavaScript callback to the click event on the relevant A element. This though is highly problematic as the click event isn't always fired when a link is activated (thus possibly resulting in normal navigation to the destination), UAs currently don't restyle As with listeners on click (nor any elements with attached listeners). A (or AREA) with @action, @method or @rel~=save would allow easy styling with CSS and ignoring. One proposal was a new download attribute. Or a parameter to data: URLs. These seem practical, as does a new rel value. A parameter to data: URLs would be a bit weird -- what if it were present in an img src, or if the user typed such a URL directly into the location bar? If the browsers UI doesn't have a Print button where the user expects one to be the UI is broken, not the document to be printed. An amazing number of users expect a print button inside the webpage itself. Whatever your opinion of this is, it's a fact. Many authors want to add print buttons inside the page to satisfy user demand, and it doesn't harm anything beyond what the page can already do (since the user can always dismiss the dialog), so it's a useful feature. True. That's why web pages should provide lots of semantic metadata to applications that may use that data to make informed decisions. Yes, like a rel=download or such, as is being proposed. I propose the method attribute on link, a and area that MUST contain a case insensitive space-seperated list of methods. A list of valid methods should be obtainable from the WHATWG wiki. Note in particular that methods are not limited to HTTP methods and neet not alter the retrieval or submission of resources, though they most certainly can. Valid methods might include: GET (retrieve resource without presenting it to the user), PUT (alter or create, akin to comp(ose) in run-mailcap), HEAD (retrieve metadata about resource), navigate (present the resource to the user). If I understand correctly, I don't think this is likely to be implemented or used enough to justify specifying it. It doesn't have clear enough use-cases.
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 8:56 AM, Thomas Koetter thomas.koet...@id-script.de wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Anything else is impossible in this case. b and i are also presentational, but the presentation cannot be separated from the semantics. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. Line breaks are not used for minor logical breaks inside paragraphs. Those are typically represented by a period. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. That would either be incorrect use of dl, or would not display as desired, or would require hiding some elements arbitrarily. address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address That requires hiding all the dt elements to achieve the same display, which is kind of ridiculous. address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address That's invalid markup. The first child of a dl (if any) must be a dt. I don't know what the semantics of dl are supposed to be with no dt. ul would work, if you really wanted, but I don't see how it's any more semantic. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property. It should already be adjustable using existing style properties, so no change is needed except possibly saying it represents a logical break instead of a line break. This is basically wrong, though, since there are lots of ways to mark up minor logical breaks, and br refers to one particular way, no other. Look at it this way: br is just a workaround for the fact that HTML ignores newlines in markup. It could have just been #10; in an alternate history. It's presentational, yes, but so are periods and commas. When I type a period, I don't want the browser to interpret that as some generic separator that it might hopefully decide to render as a period, I want *a period*. Exactly that, nothing else. Likewise for newlines. We don't need to impose some abstract semantic meaning on *everything*. Some presentation is so closely tied to the meaning of the document that it can't reasonably be abstracted away. This is true for b, i, sup, sub, and br, among others.
Re: [whatwg] Form validation against invisible controls
On Fri, 4 Jun 2010, TAMURA, Kent wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) The problem with that is that they still get submitted, so it seems weird to not validate them. It seems authors should be careful not to make the hidden controls be invalid. On Thu, 3 Jun 2010, Tab Atkins Jr. wrote: Adding @hidden to the list of things that skip validation is good. I considered it, but really we should also also stop submission in that case, and that seems like it's starting to make things a little less intuitive than I'd like. It's really up to the author to make sure that something that's irrelevant (hidden=) is not part of a form that is user-submittable. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. Indeed. On Fri, 4 Jun 2010, TAMURA, Kent wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. I think, as the sentence above suggests, it's better to report this as a page error than to not validate the control. Chrome already reports this problem in the console. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. On Thu, 3 Jun 2010, Peter Kasting wrote: I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the hidden attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. Indeed. On Mon, 14 Jun 2010, TAMURA, Kent wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. Just don't autofill controls with invalid values, and don't autofill hidden controls. :-) On Mon, 14 Jun 2010, Ola P. Kleiven wrote: The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. Do you have more specific URLs I could look at for these? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sort child nodes of a DOM node.
On Fri, 4 Jun 2010, Biju wrote:
There are many cases where we want to sort child nodes of a DOM node.
Many times it is TR nodes of a TBODY
Right now user writes javascript code to achive that.
Dont you think it is better if there was built DOM method for each node.
Additionally the method will have a sort function parameter to compare
elements
the same way as in JavaScript Array.sort(compare_func)
function compare_func(a,b){
if(isHeaderRow(a)) return -1;
if(isHeaderRow(b)) return 1;
if(a.textContent == b.textContent) return 0;
if(a.textContent b.textContent) return -1;
return 1;
}
tablebody.sortChildNodes(compare_func)
Use cases:-
Example 1: column sorting in yahoo mail
Example 2: you can sort this listing by clicking the column headers
https://bugzilla.mozilla.org/buglist.cgi?short_desc=sortshort_desc_type=allwordssubstrresolution=---
Example 2: there are bug report in mozilla asking sorting in XUL grids
https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890hide_resolved=1
This would indeed be useful. It seems like something that should be in DOM
Core, though, rather than HTML. Do we have anyone editing Web DOM Core
these days?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell slightly...@google.com wrote:
Sorry for the lagged response,
On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt oli...@apple.com wrote:
On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
The e-mails quoted below consist of the salient points of this thread:
On Fri, 23 Apr 2010, David Bruant wrote:
Make that HTMLCollection (and all HTML*Collection, as a consequence of
inheritence of HTMLCollection) inherit from the ECMAScript Array
prototype. This way, it will make available all Array extra methods
(forEach, map, filter...) added in ECMAScript5 (and next versions which
should go in the same direction).
As far as I know, adding this won't break any existing code. The
semantics of a Collection and the way it is used is very close from
ECMAScript Arrays. I don't think that the notion of live object and
ECMAScript Array are incompatible either. Once again, I am talking about
ECMAScript binding. I have no intention to touch the HTMLCollection
interface or other languages bindings.
On Sun, 25 Apr 2010, J Z wrote:
If HTMLCollection was inheriting from Array, and methods like `forEach`,
`map`, etc. were to operate on a live object, there would definitely be
undesired consequences. We can see this in, say, Firefox (which allows to
set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
HTMLCollection.prototype.__proto__ = Array.prototype;
document.getElementsByTagName('div').forEach(function(el) {
el.parentNode.removeChild(el); // doesn't work as expected
});
// turning live collection into static array fixes this
Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
el.parentNode.removeChild(el);
});
On Sat, 24 Apr 2010, David Bruant wrote:
I think I can take your point as a pro more than a con, because in
ES5, right before the definition of each array extra method, a paragraph
like the following can be found :
The range of elements processed by forEach is set before the first call
to callbackfn. Elements which are appended to the array after the call
to forEach begins will not be visited by callbackfn. If existing
elements of the array are changed, their value as passed to callback
will be the value at the time forEach visits them; elements that are
deleted after the call to forEach begins and before being visited are
not visited.
This point is confirmed by every algorithm where the length is saved
once for all before the loop and not got from the .length property each
time.
On Mon, 26 Apr 2010, Erik Arvidsson wrote:
On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
Le 25/04/2010 00:39, J Z a écrit :
I have thought a lot about weirdnesses that people could think about
like trying to assign a value to the HTMLCollection (divs[14] =
myOtherDiv), but once again, it wouldn't be more allowed than it
currently is (I have no idea of what happens today, but if an error
is thrown in a for-loop, it should throw an error as well in a call
within a forEach).
How would destructive methods like `push` or `sort` behave? Would
`document.body.childNodes.push(document.createTextNode('foo'))` append
text node to a body element? Or would it be a noop?
That is actually a very good point. It think that the behavior should
be exactly the same as an equivalent without array methods. (this
point of my proposal would need to be made completly explicit for each
method)
One way to solve this could be to split Array into two interfaces. One
to be used with immutable array like objects and one to use to mutate
objects. Then we could apply the immutable array like interface to
NodeList and its related interfaces. The benefit of doing that is that
NodeList.prototype.push would be undefined instead of failing when
called.
On Mon, 26 Apr 2010, David Flanagan wrote:
Rather that trying to make DOM collections feel like arrays, how about
just giving them a toArray() method? This makes it clear that a
collection is not an array, but clearly defines a way to obtain an
array. Clever implementors might even be able to optimize common
uses-cases using some kind of copy-on-write strategy so that toArray()
doesn't involve memory allocation and copying.
Of course, trying to teach programmers when they ought to call toArray()
and when it is not necessary is another matter. Perhaps calling the
method snapshot() and focusing on the live vs. static distinction
instead of the fake array vs. true array distinction would invite less
misuse.
Or we can just leave the DOM as it is and get used to calling the
equivalent of Prototype's $A() function.
Before changing something this substantial, I'd like to have implementor
feedback regarding what the best way to address this is:
- somehow make HTMLCollections and NodeLists inherit from Array?
- define a
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Aug 4, 2010, at 2:40 PM, Jonas Sicking wrote: On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell slightly...@google.com wrote: Sorry for the lagged response, On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt oli...@apple.com wrote: On Jul 30, 2010, at 2:46 PM, Alex Russell wrote: Wait...what? Shouldn't some sort of NodeList be mutable? And shouldn't JS support immutable Arrays? We need to fix both of these APIs, and we keep heaping back-pressure on JavaScript's Array without any reasonable resolution because we're not exploring how to make Array subtypes work as we want them to for all the use cases (like this) that we care to express. What would you expect a mutable NodeList to be? A good example would be the result of document.querySelectorAll(). Why couldn't querySelectorAll return a normal Array? I think in principle it could, but it might be too much compat risk to do now. Returning a fully mutable array would also remove the opportunities to cache and reuse the return value, since each result would really need to be distinct if they are mutable. Regards, Maciej
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 8/4/10, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell slightly...@google.com
wrote:
Sorry for the lagged response,
On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt oli...@apple.com wrote:
On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
The e-mails quoted below consist of the salient points of this thread:
On Fri, 23 Apr 2010, David Bruant wrote:
Make that HTMLCollection (and all HTML*Collection, as a consequence
of
inheritence of HTMLCollection) inherit from the ECMAScript Array
prototype. This way, it will make available all Array extra methods
(forEach, map, filter...) added in ECMAScript5 (and next versions
which
should go in the same direction).
As far as I know, adding this won't break any existing code. The
semantics of a Collection and the way it is used is very close from
ECMAScript Arrays. I don't think that the notion of live object and
ECMAScript Array are incompatible either. Once again, I am talking
about
ECMAScript binding. I have no intention to touch the HTMLCollection
interface or other languages bindings.
On Sun, 25 Apr 2010, J Z wrote:
If HTMLCollection was inheriting from Array, and methods like
`forEach`,
`map`, etc. were to operate on a live object, there would definitely
be
undesired consequences. We can see this in, say, Firefox (which
allows to
set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
HTMLCollection.prototype.__proto__ = Array.prototype;
document.getElementsByTagName('div').forEach(function(el) {
el.parentNode.removeChild(el); // doesn't work as expected
});
// turning live collection into static array fixes this
Array.slice(document.getElementsByTagName('div')).forEach(function(el)
{
el.parentNode.removeChild(el);
});
On Sat, 24 Apr 2010, David Bruant wrote:
I think I can take your point as a pro more than a con, because
in
ES5, right before the definition of each array extra method, a
paragraph
like the following can be found :
The range of elements processed by forEach is set before the first
call
to callbackfn. Elements which are appended to the array after the
call
to forEach begins will not be visited by callbackfn. If existing
elements of the array are changed, their value as passed to callback
will be the value at the time forEach visits them; elements that are
deleted after the call to forEach begins and before being visited are
not visited.
This point is confirmed by every algorithm where the length is
saved
once for all before the loop and not got from the .length property
each
time.
On Mon, 26 Apr 2010, Erik Arvidsson wrote:
On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
Le 25/04/2010 00:39, J Z a écrit :
I have thought a lot about weirdnesses that people could think
about
like trying to assign a value to the HTMLCollection (divs[14] =
myOtherDiv), but once again, it wouldn't be more allowed than it
currently is (I have no idea of what happens today, but if an error
is thrown in a for-loop, it should throw an error as well in a call
within a forEach).
How would destructive methods like `push` or `sort` behave? Would
`document.body.childNodes.push(document.createTextNode('foo'))`
append
text node to a body element? Or would it be a noop?
That is actually a very good point. It think that the behavior
should
be exactly the same as an equivalent without array methods. (this
point of my proposal would need to be made completly explicit for
each
method)
One way to solve this could be to split Array into two interfaces.
One
to be used with immutable array like objects and one to use to mutate
objects. Then we could apply the immutable array like interface to
NodeList and its related interfaces. The benefit of doing that is
that
NodeList.prototype.push would be undefined instead of failing when
called.
On Mon, 26 Apr 2010, David Flanagan wrote:
[snip]
To all, please trim quotes to a minimum - thanks.
What would you expect a mutable NodeList to be?
A good example would be the result of document.querySelectorAll().
Why couldn't querySelectorAll return a normal Array?
It could have done that. It would not be immutable. How much
interoperability issue would changing it now cause? Array could be an
ECMA binding as a potential consideration as an idea for alternative
to non-live static nodelist.
Changing live collections to be Arrays would cause severe
interoperability problems. It would be very complicated.
Then if you're going to get an array, it should be possible to set an
array. I suppose in this sort of situation a setItems method could be
useful:
var cells = Array.prototype.slice.call(row.cells).sort( comparator );
row.childNodes.setItems( cells );
The first line is a bit ugly and so it would be nice to have it a more
succinct, not to save typing,
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 8/4/10, Garrett Smith dhtmlkitc...@gmail.com wrote: [...] submitButton in form.elements Existing implementations vary on when they use catchalls. I'd like to see standardization for this behavior and codification so that implementations behave similarly -- either use a catchall for a particular type of collection or use a native object. If a catchall is Native object either way, but either with a new ES catchall behavior or with a native ES object, as specified today. Garrett
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, 4 Jun 2010, Smylers wrote: The HTML5 spec should define how to mark up the main content on a page (even if the answer is by omission). This is something that many authors ask about, the latest example being today's thread on the help mailing list: http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html Please could this be added to the 'idioms' section, perhaps giving examples of when article or section might be appropriate as well as one in which the main content is simply that which isn't in header, aside, etc. Done. On Fri, 4 Jun 2010, Daniel Persson wrote: I am the one posting the question on the help list. To me, the lack of html5 definition of main content, ie body copy in paper publishing, is a big mistake. Imagine the amount of sites where everything else includes a lot of unimportant extra, or peripheral, content. Content which is not necessarily hierarchically legible by a machine. Getting authors to be disciplined about defining main content is more important than being disciplined about nav, footer, header, section etc, in order not to negate the meaning of html5 structural mark-up. Suggestion bodycopy... or, preferred, bread. Getting authors to be disciplined about defining main content is in fact the same as being disciplined about nav, footer, header, etc, because the main content is anything not in those elements. On Fri, 4 Jun 2010, Daniel Persson wrote: Some websites are very crowded. I have no particular example. Blogs and easily accessible CMS's, people trying to make a buck from excessive advertising on their site, people cramming a lot of info/screen unit. Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper, watch your eyes) . body will hold a lot of stuff that is not main content, other content will spill over into body (unless there is a conscious author, and vast use of aside). It should be easy for authors to define main content. It s a pedagogical issue, where authors not too concerned with standards compliance, should have an easy escape of at least defining the most important on the site. We could either mark up what's the main content, implying that everything else is not the main content, or mark up what's not the main content, implying that everything else is the main content. We've gone with the latter, because it turns out that the main content's presentation is usually just the default, whereas everything else needs to be styled specially, so people usually want to wrap the non-main-content. However, there are cases where you also want to wrap the main content. For those cases, we have article, section, and div (in increasing order of vagueness). On Fri, 4 Jun 2010, Tab Atkins Jr. wrote: Authors can either use aside to mark up all the irrelevant stuff on their page that isn't main content, or they can wrap the main content in an article (not ideal, but workable). Actually it's pretty much what article was meant for. On Mon, 7 Jun 2010, Daniel Persson wrote: What I am taking about is that it is upside down to expect honest people to define everything except the main content. Pedagogically and methodologically. Main content is main content, the most important to define. That should be the starting point for the structure. I don't understand why. Think of a sentence: I like kittens (and cats). The important content is I like kittens. The less important content is and cats. We mark up the less important content. The simplest tutorial on html5 authoring should be: Getting doctype and charset right, html, head, body. Then define main content. Finished. Ready to be indexed. I don't see why the define main content step is useful. What problem does it solve? ...bu at least the main content (as defined by the author) can be reached, indexed, sorted or stacked by machines. This seems to be a solved problem today, without any markup. On Fri, 4 Jun 2010, Aryeh Gregor wrote: It's unwise to omit body unless you can guarantee that the first element in the body will actually trigger the end of the head. In your case, I believe that at least IE will put aside and article in the head, because it doesn't recognize them as only belonging in the body. (It seems like the HTML5 parser does put it in the body -- although as far as I can tell, this means we can never introduce new elements that can go in the head.) We just add them to the list of elements that go in head, and wait a few years. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sort child nodes of a DOM node.
On Fri, Jun 4, 2010 at 1:49 AM, Biju bijumaill...@gmail.com wrote:
There are many cases where we want to sort child nodes of a DOM node.
Many times it is TR nodes of a TBODY
Right now user writes javascript code to achive that.
Dont you think it is better if there was built DOM method for each node.
Additionally the method will have a sort function parameter to compare
elements
the same way as in JavaScript Array.sort(compare_func)
function compare_func(a,b){
if(isHeaderRow(a)) return -1;
if(isHeaderRow(b)) return 1;
if(a.textContent == b.textContent) return 0;
if(a.textContent b.textContent) return -1;
return 1;
}
tablebody.sortChildNodes(compare_func)
Use cases:-
Example 1: column sorting in yahoo mail
Example 2: you can sort this listing by clicking the column headers
https://bugzilla.mozilla.org/buglist.cgi?short_desc=sortshort_desc_type=allwordssubstrresolution=---
Example 2: there are bug report in mozilla asking sorting in XUL grids
https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890hide_resolved=1
This sounds more akin to the thread with the subject line Adding ECMAScript
5 array extras to HTMLCollection
It's already easy enough to do once you've copied the nodes into an array:
var rowsArray = convertNodeListIntoJSArray(tBody.rows); // assuming you've
written such a function
rowsArray.sort(compare_func);
tBody.innerHTML = ;
rowsArray.forEach(function(row) { tBody.appendChild(row) });
I'd rather just see some kind of resolution to mixing in Array methods into
the HTMLCollection object. Since HTMLCollection objects are often 'live' it
would just be:
tBody.rows.sort(compare_func);
I have no opinion on how Array methods should be mixed into HTMLCollection
objects, since the difficulty seems to be more in implementation than
devising a web authors' wishlist, but that's what I'd rather see.
--
Jon Barnett
Re: [whatwg] bubbling events on labels
On Fri, 4 Jun 2010, Diego Perini wrote: I have different behavior in browsers with the checked state of a checkbox input element. I have filed a ticket in Webkit and I am looking after some advice/suggestion about the correct behavior expected from this HTML: label input type=checkbox a href=#Enable/a /label It seems Safari/Chrome are discarding the click bubbling at the link level, thus never reaching the label and not toggling the checkbox. The behavior in Firefox/Opera and in Safari/Chrome is different and the checkbox is correctly checked (as I would have expected). Should a click on the link make the input checked ? On Fri, 4 Jun 2010, Tab Atkins Jr. wrote: As far as I can tell, section 3.5.2.1.7 (Interactive Content) specifies that clicking the link in that situation should activate the link and not toggle the checkbox. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [br] element should not be a line break
Thomas wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. I agree. Other elements have been redefined to remove medium-specific descriptions from their definitions (b, i, and hr, specifically). It seems logical to me that br should get the same treatment. timeless wrote: The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. The suggestion, as far as I understand it, is not to change how the element *works* in browsers, but merely to redefine its meaning as a minor logical break rather than a line break. The default browser styling would not change. Aryeh wrote: Anything else is impossible in this case. b and i are also presentational, but the presentation cannot be separated from the semantics. This is no longer true. The semantics of b and i have been changed in HTML5, specifically to separate the presentation from the meaning. Specifically, any reference to screen- or page-specific styling like bold and italic have been removed (allowing the elements to still have meaning in a medium such as audio). I like Thomas's suggestion (or, at least, I like it as much as any of the semantic redefinitions being applied to formerly-presentational elements). The hr element is currently defined as a paragraph-level thematic break. I think br could be defined as a text-level thematic break. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Why is DOMContentLoaded event not bubbling?
On Sun, 6 Jun 2010, Nickolay Ponomarev wrote: Currently DOMContentLoaded is specified [1] with this sentence: Queue a task to fire a simple event named DOMContentLoaded at the Document. and fire a simple event is defined [2] as does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated). So it's not bubbling and, as far as I understand, per [3] it means it doesn't bubble to Window. I checked Gecko (trunk), Safari (4), Chrome (6) and in all of them it bubbles to window and reports itself as bubbling. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What is not possible with HTML5
On Mon, 7 Jun 2010, narendra sisodiya wrote: For example video telephony in browser is possible? I sent some comments regarding this topic recently: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027129.html On Mon, 7 Jun 2010, narendra sisodiya wrote: I clearly see the huge market in Virtual worlds like second life and augmented reality in mobile phones. WebGL is a rendering specification. I think , on top of webGL , we may need some higher order specification for 3D web. Who know, HTMLx may include 3dwall orientation='right' id='facebook-wall' / type of tags, Anyway , I am a strong believer of Matrix. We will be having a similar sort of Matrix is future. So It is the question of future that - 'will Matrix us flash/sliverlight or Open Standards' If All of sudden we got huge bandwidth and second life will be most popular web browser. in second life one can have a 2D browser and other technologies. I was just trying to have a discussion of future version of HTMLx , open standards and future technologies... I have seen a 'lazy web' nature. first close standards comes and then we fight for an equivilant open standard. That's one way to put it, though I would personally describe it as allowing innovation to happen and then standardising what is successful. Another way to put it is in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F On Thu, 24 Jun 2010, Julian Reschke wrote: On 24.06.2010 16:03, Marques Johansson wrote: I would like to see a standardization of HTTP streaming, not necessarily adaptive streaming - but that could also be useful. The HTTP spec is vague or incomplete on behaviors related to partial requests. ... If you think that there is a bug in the HTTP spec then by all means check out the latest drafts, and in doubt report this on the HTTPbis WG's mailing list (pointers: http://tools.ietf.org/wg/httpbis/). Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote: On 8/4/10, Garrett Smith dhtmlkitc...@gmail.com wrote: [...] submitButton in form.elements Existing implementations vary on when they use catchalls. I'd like to see standardization for this behavior and codification so that implementations behave similarly -- either use a catchall for a particular type of collection or use a native object. If a catchall is Native object either way, but either with a new ES catchall behavior or with a native ES object, as specified today. Garrett As a question, if the node lists were implemented as catchalls, how would the behaviour differ from current NodeLists? The only change I can see would be the loss of the host object exceptions in the ES spec, but that just puts you in the position of having semantics that match the current host object behavior in those implementations that already allow array functions to operate on host objects. --Oliver
Re: [whatwg] [URL] Starting work on a URL spec
On Tue, 03 Aug 2010, Adam Barth w...@adambarth.com wrote: On Tue, Aug 3, 2010 at 8:21 AM, bjartur svartma...@gmail.com wrote: On 7/25/10 8:57 AM, Adam Barth wrote: It may not be an _html_ interoperability problem, but it's certainly a _web_ interoperability problem. It's a question of how HTTP messages are encoded (and in special the enco= ding of the IRI). WHATWG does not specify HTTP, these concerns should be directed to IETF. There are various ways to spec lawyer things so you can make this work appear to be the responsibility of various folks. The work needs to be done. I'm inclined to do the work first and worry about what organization (if any) has jurisdiction later. Yeah, true. I've been through a repetive ask the county ask school authorities, ask the county when asking my school to implement a SHOULD from national gov. *shrugs* But really, you should discuss this with the HTTP WG of IETF by raising the issue in http...@hplb.hp.com. I recommend searching the archives, http://www.ics.uci.edu/pub/ietf/http/hypermail, for counter-arguments before posting as this issue has probably be raised before. Then someone should fork RFC 2616 (or the latest working draft, if there's a current one). Patching the RFC == doing the work (good lucking getting consensus on your side if you don't provide rationale, don't defend your decisions and ignore the IETF though)
Re: [whatwg] HTML resource packages
2010/8/4 Kornel Lesiński kor...@geekhood.net On 4 Aug 2010, at 11:46, Diego Perini wrote: * Argument: What about incremental rendering? If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough. ZIP files are progressively renderable, dependant on file order. In my experience gzip compression is blocking browser rendering until the compressed file has been received completely. I believe this is the reason we should not compress the HTML source, just its external binary components. I don't think the browser can separately decompress each block of a chunked transfer as it arrives, am I wrong ? You are wrong. gzip compression is streamable and browsers can uncompress parts of gzipped file as it is downloaded. gzip only needs to buffer some data before returning uncompressed chunk, but it's only few KB. Chunks of gzipped data don't have to align with chunked HTTP encoding (those are independent layers). Tank you for the informations and correcting my statements. I just tried and definitely chunked and gzip compression can happen at the same time. The problem is I have a strange effect on my pages if I enable Apache SetOutputFilter DEFLATE, the pages progress and rendering are different. It works well with zlib.output_compression, more or less with no visible changes from non compressed. I will have to dig what makes this difference. Diego Perini -- regards, Kornel
Re: [whatwg] Proposal for Web Storage expiration
So given no strenuous objections, can we make expiration for Web Storage real? :) -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, August 04, 2010 10:26 AM To: Jeremy Orlow Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal for Web Storage expiration On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. I'm definitely for expiration of localStorage values. Though I think it also makes sense to do for IndexedDB. Especially if it can be done on a per-objectStore basis as that makes it very low overhead. / Jonas
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 8/4/10, Oliver Hunt oli...@apple.com wrote: On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote: On 8/4/10, Garrett Smith dhtmlkitc...@gmail.com wrote: [...] submitButton in form.elements Existing implementations vary on when they use catchalls. I'd like to see standardization for this behavior and codification so that implementations behave similarly -- either use a catchall for a particular type of collection or use a native object. If a catchall is Native object either way, but either with a new ES catchall behavior or with a native ES object, as specified today. Garrett As a question, if the node lists were implemented as catchalls, how would the behaviour differ from current NodeLists? The externally observable behavior wouldn't have to change. [[HasProperty]] checks (using `in`) with catchalls have sometimes unexpected results, so I wouldn't want to see that kind of change. Try some of the tests here: http://jibbering.com/faq/names/extra_props.html The article needs a little updating but the examples I'm referring to demonstrate disparity with `in` operator: FF3.6 'test' in this.form true 'test' in this.form.elements false A catchall should possible for a result of `null` for indexed access. This probably isn't adding any value over returning `undefined` because many implementations will result `undefined` for property access and most programs won't care one way or the other (and if they do, they're not interoperable with existing browsers). I want the specs to codify behavior of existing various collections and to do that, I want to figure out where and why catchall is used. I can't answer as to why Gecko uses a catchall; perhaps some of the Mozilla devs on this list can give further info. Perhaps there is behavior for past names map that requires catchall (I don't think anybody is a big fan of past names map). The only change I can see would be the loss of the host object exceptions in the ES spec, but that just puts you in the position of having semantics that match the current host object behavior in those implementations that already allow array functions to operate on host objects. The semantics for native object are defined by ECMA-262. If collection is required to be implemented as a native ECMAScript object, then it would still be considered a host as a native object, would be indistinguishable from other native objects, both internally and externally, and so would not be subject to ES whether or not the xxx method may be applied to a host object loopholes. Thus, [].slice.call( ho ) could be expected work. It would have to work because Array.prototype.slice would have no way of determining that `ho` is a host object; it would simply see that it is passed in a native object. It would not be able to differentiate or discriminate between that and a user-defined object. All that would be necessary to make that happen would be to state that the collection -- NodeList, for example -- is implemented as a native ECMAScript object. That alone would be enough to guarantee that any native operation would have results that could be expected. Again, from ES point of view, there are two types of host objects: 1) host object implemented as a native object 2) host object implemented with other semantics Garrett
Re: [whatwg] Form validation against invisible controls
The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. Please look at the original report and Comment #4. It is not an auto-fill issue. Comment #2 is an auto-fill bug and it was moved to another bug entry. Regardless of the auto-fill bug, we still have compatibility issues and we can't force authors to update their web pages. I'm wondering UA should show a dialog with The web page has invisible invalid form fields. Do you want to submit the form? [Yes] [No]. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] INCLUDE and links with @rel=embed
On Tue, 18 May 2010, bjartur wrote: First of all I think we should use a rel=embed href=uri-ref instead of source. What problem would this solve? It would tell UAs that don't implement HTML 5 that the value of @href is an URI. Then it can provide means for the user to retrieve the identified resource (and do something useful with it). For authors it would unnecessiate constructs such as (excerpt from spec): video controls src=http://video.example.com/vids/315981; a href=http://video.example.com/vids/315981;View video/a. /video In fact, having the ability to follow this link is useful even though my browser supports video. But that's an UI issue. On Wed, 19 May 2010, Bjartur Thorlacius wrote: Is the existing syntax backwards compatible? When using A, you get a nice link as fallback content automagically, not requiring any special workarounds by the content author. AFAICT you don't even get that when using a browser that doesn't support audio and video. Indeed, with those you have to provide the fallback content (which could e.g. be flash) as a descendant of the audio/video element. As a user of a browser that doesn't fully support video I'd prefer getting a hyperlink to the resource to a Flash program. Just sayin'. What I'm trying to write is that not all browsers support JavaScript, not all pages must be able to control playback more than play, pause, seek etc and that a mechanism for linking to files and alternative encodings thereof semantically. Currently, that seems to be only possible with video and audio. But if you create a media element that adds no extra interface, you get this for all other types as well (albeit with a lesser scripting interface). Although the include element won't be as good integration point between one media and scripts, it will have a standard interface somewhat applicable to many medias/mediums and at least provide something to all medias, versus (close to) nothing. I'm not sure I follow. If you're saying that we should also support other timed-based formats in the future even if they are not video, e.g. if you are saying we should support formats like SMIL, then there's no reason you can't do that with video itself. video really is just an API to time-based visual data, it doesn't have to be a sequence of bitmaps. Oh, the following quote confused me. The video element is a media element whose media data is ostensibly video data I'm not just talking about SMIL. I'm talking about using a secondary feature of media elements (the ability to link to multiple alternative resources) even if the main feature (the API) is irrelevant. video source src=f.utf8 charset=utf8 source src=f.latin1 charset=latin1 /video video source src=img.png type=image/png source src=img.svg type=image/svg+xml /video I don't need to know the duration of an unanimated PNG. On Wed, 19 May 2010, bjartur wrote: Yeah, maybe my crazy idealism and tendency to reuse existing things don't mix up in this case. The main purpose of video and audio is to create a scripting interface to online video. But they also add new linking capabilities which should be available to any content whatsoever. I don't really see how. In what sense do they add new linking capabilities? In the sense of multiple alternative (media) resources. This could possibly be done with object but its fallback mechanism seems inferior.
