Re: [whatwg] Input URL State and Files object
Why wouldn'tinput type=file be usable for this? You should be able to drag any file to that, just like you can type in a URL in Windows in an open file dialog box. input type=file would be usable. Were this implemented: When a user through selection, click+drag or manual entry of a URL should the browser still submit an Origin request header? It seems that CORS doesn't come into effect here -- but at the same time, it'd be handy for logging purposes and added security. When a cross-site resource is fetched via CORS, the agent submits an Origin header. A secure site (such as a bank), may always return a Forbidden response if the Origin header is set; blocking any kind of cross-site sharing, even sharing attempted by a user (through an input type=file field). On Windows at least, when put a URL in the open dialog the shell downloads it then passes a temporary file. The browser never gets the source URL - so it'd be difficult without re-implementing the dialog (undesirable). Plus user control, and all that. -- James
Re: [whatwg] Race condition in media load algorithm
On Tue, 03 Aug 2010 00:40:26 +0200, Chris Pearce ch...@pearce.org.nz wrote: On 2/08/2010 9:17 p.m., Ian Hickson wrote: On Mon, 2 Aug 2010, Chris Pearce wrote: There's a race condition in the media load algorithm. When the resource selection algorithm begins, it sets a task to complete the rest of the resource selection algorithm asynchronously. Not quite. It awaits a stable state and then runs a synchronous section, which means that it will run the subsequent steps as soon as the current task has finished, before anything else that is queued. Ah, I see. My understanding of the processing model was incomplete, thanks for clarifying! For the record, here's how I interpreted await a stable state: The only state that is not stable is a running script. The only step in any video-related algorithm one can reach from a script is step 2 of the resource selection algorithm. Therefore, when reaching that step, if the resource selection algorithm was triggered by a script, wait until that script has finished and then continue. The only somewhat tricky part is that if we are in an event handler triggered by script, we should wait until the script that triggered the event handler has finished. The only way I know of triggering this corner case is by invoking a synchronous event handler from script, e.g. by calling click(). All other occurrences of await a stable state I've ignored as we can't not be in a stable state when reaching them. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Please consider simplifying authoring guidance for the img alt attribute
On Tue, 2010-08-03 at 11:58 +0200, Markus Ernst wrote: Am 02.08.2010 20:54 schrieb Ashley Sheridan: On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote: - search engines should generally ignore text in the alt attribute, but evaluate the title attribute instead Rationale: 4.8.1.1.12 says: A corollary to this is that the alt attribute's value should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image. The title attribute can be used for supplemental information. What you said doesn't make sense. The alt text is to be used instead of the image, and the title is for supplemental content. Therefore, search engines should use alt text, as that is what they are attempting to convey in the lost (in the sense that search engines don't process images like they do text) image. If they used the title, one can only imagine the trouble. Ok, maybe the search engine aspect obfuscates the main statement I wanted to make; let's just drop it and try to be some more specific. 4.8.1.1 says: Except where otherwise specified, the alt attribute must be specified and its value must not be empty; the value must be an appropriate replacement for the image. The specific requirements for the alt attribute depend on what the image is intended to represent, as described in the following sections. In the sub sections, many cases are stated where the alt attribute must be set to the empty string, and some cases where the alt attribute can even be omitted. These seem to be the ones that are considered to be too complicated. My point is, that it would simplify things (e.g. the cases treated in the links Tantek provided) a lot to do it the other way around: - Declare the alt attribute as optional, and default a missing alt attribute to alt= - Explicitly specify the cases where the alt attribute must be set (e.g.: if the image is the only child of an a or h1-6 element) - Update some of the authoring guidance in the sense of encouraging authors to apply alt text where appropriate, and omit it where not (I specially think of 4.8.1.1.9 here; I will post a separate proposal about this section) I doubt that there is much benefit in the requirement for the alt attribute, for the following reasons: - The paedagogig aspect of making a document invalid if an alt attribute is omitted is obsolete, as authors have got used to just insert alt= if they are too lazy to write an alternative text, and many authoring tools even insert the empty string by default if the author does not specify an alt text. Bad authoring cannot be prevented by structural specification. - I have no personal experience using screen readers or text-only browsers, but I am quite sure that unnecessary (not speaking of inadequate) alt text is not helpful, but even harmful as it interrupts the reading or listening flow. (If screen reader or braille browser users contradict me here, I am happy to learn, of course.) If the content of the alt attribute is interrupting the flow of the text, then it is either not describing the image it represents well, or the image is not something which should appear in the flow of text at that position. HTML5 brings many new layout devices which can help lay out the code in a logical and coherent manner, while still rendering on screen in the traditional manner. I do test thing in text browsers, and frequently see bad alt text markup on sites along the lines of alt=Company Logo or somesuch, where in-fact it should have read alt=ACME Trading Co. because that is the text that was on the image anyway. I agree that there is a lot of bad markup out there with lots of empty alt attributes, inserted only to pass the validators, but I think making the attribute optional would just cause further accessibility issues. Better to improve the validators to give warnings about empty alt attributes (only warnings rather than outright errors) to notify the developer that there could be a potential issue with the markup. Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Proposal for an addition to the authoring guidance regarding the alt attribute
Section 4.8.1.1.9 describes how alternative text for content images should be written: http://www.w3.org/TR/html5/embedded-content-1.html#a-key-part-of-the-content Then, there is a general guideline about writing alternative texts in section 4.8.1.1.12: A corollary to this is that the alt attribute's value should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image. The title attribute can be used for supplemental information. IMO the wording of 4.8.1.1.9 is somehow contradictive to the general guidance in two cases: 1. The image is the information itself, it does not convey any information beyond it's visuals. This is a very common case, for example in photo galleries. Unlike the examples given under The general case (where lack of the image is lack of information), the images in a wedding photo gallery cannot be described in a way that matches 4.8.1.1.12 and provides any useful information for e.g. a blind user. The information Me, Gary, and his parents eating the cake is rather useful for those who actually see the image, and should go to the caption, as correctly stated in 4.8.1.1.12. 2. The image illustrates what is discussed in the surrounding text, or has a caption describing it. Inserting alt text would actually duplicate the information, but not convey anything useful for those who don't see the image. IMO alternative text should be omitted in this case (as e.g. Wikipedia does: http://en.wikipedia.org/wiki/Squirrel - the alt attribute values of all content images are empty). So I propose to: - Explicitly treat these two cases in 4.8.1.1.9, requiring to insert no alt text there - In the part Images whose contents are not known, remove the word unfortunate at the beginning (In some cases), and the first note. (Apparently, the W3C itself is not so sure about alt text in content images; http://www.w3.org/Consortium/mission illustrates this: There is a picture of Tim Berners-Lee, with no direct reference in the text. It does not seem to be decorative, as according to 4.8.1.1.6 the alt attribute should be empty in this case; but the alt text says: Tim Berners-Lee speaking at W3C10, which is not an information conveyed by the image itself if you don't know how Tim Berners-Lee looks like. Thus, according to 4.8.1.1.9, this information should be displayed in a caption, and the alt attribute should say something like A male speaker in front of a display containing the text 'W3C10 Tenth Anniversary' and some sponsor logos - which is of course stupid. The empty string would IMO be the appropriate value for the alt attribute here.)
Re: [whatwg] Input URL State and Files object
On Tue, Aug 3, 2010 at 9:18 AM, James May wha...@fowlsmurf.net wrote: On Windows at least, when put a URL in the open dialog the shell downloads it then passes a temporary file. The browser never gets the source URL - so it'd be difficult without re-implementing the dialog (undesirable). Plus user control, and all that. Actually, this is not a mandatory feature of the Windows file picker, the application can provide its own handling if it so wishes. Whether that applies to other platforms' file pickers, I'm not certain.
Re: [whatwg] [URL] Starting work on a URL spec
On 7/25/10 8:57 AM, Adam Barth wrote: There's also the related question of what browsers should do with input typed into the URL field. Other than establishing that these rules may be different between the URL field and URLs present in content, I'm not sure this is amenable to spec. But perhaps a survey of what browsers do would be useful. I wasn't planning to cover that because it's not a critical to interoperability Unfortunately, it is. In particular, servers need to know what to expect the browser to send if a user types non-ASCII into the url bar. There are real interoperability problems out there due to differing server and browser behavior in this regard. 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 encoding of the IRI). WHATWG does not specify HTTP, these concerns should be directed to IETF.
Re: [whatwg] [URL] Starting work on a URL spec
On Tue, Aug 3, 2010 at 8:21 AM, bjartur svartma...@gmail.com wrote: On 7/25/10 8:57 AM, Adam Barth wrote: There's also the related question of what browsers should do with input typed into the URL field. Other than establishing that these rules may be different between the URL field and URLs present in content, I'm not sure this is amenable to spec. But perhaps a survey of what browsers do would be useful. I wasn't planning to cover that because it's not a critical to interoperability Unfortunately, it is. In particular, servers need to know what to expect the browser to send if a user types non-ASCII into the url bar. There are real interoperability problems out there due to differing server and browser behavior in this regard. 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 encoding 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. Adam
Re: [whatwg] Race condition in media load algorithm
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. 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. -Boris
Re: [whatwg] Simple Links
On Tue, Jul 27, 2010 at 3:13 PM, Ian Hickson i...@hixie.ch wrote:
I also randomly picked a Wikipedia page (Potato) and looked at some of th=
e
links there. The only link that matched that pattern on the whole page wa=
s
in the footer that only gets displayed in the print media:
=C2=A0 div class=3Dprintfooter Retrieved from a href=3Dhttp://en.w=
ikipedia.org/wiki/Potatohttp://en.wikipedia.org/wiki/Potato/a/div
It's also presented to unknown UAs (as Wikimedia assumes they're dumb bots).
For what it's worth, this is because the href's in the articles
themselves have /wiki/ prepended (a href=3D/wiki/Potato, not a
href=3DPotato). In turn, this is because the pages can actually be
served from multiple directories: http://en.wikipedia.org/wiki/Potato
is the same as http://en.wikipedia.org/w/index.php?title=3DPotato.
(There are actually some differences at the moment if you do a diff,
but that's because they're cached separately by Squid. If you log in,
the differences should disappear.) So href=3DPotato would do the
wrong thing in the latter case.
Indeed, in a dynamic web application, something like href=3DPotato is
practically useless unless you can guarantee that you're always
rewriting URLs to look pretty and conceal the actual script serving
the request. So in particular, MediaWiki could not use the proposed
a href syntax.
I consider the equivalence of /wiki/Potato and /w/index.php?title=Potato
a bug. Metadata such as the URI of the document can be served by various
means, such as the Location header in HTTP, and a seperate base URI to
use for relative linking can be specified with the base element in HTML.
Ian Hickson:
On Tue, 30 Mar 2010, Christoph P=E4per wrote:
I wonder whether HTML could and should provide some sort of similar =
shortening, i.e. =93a hrefFoo/a=94 or even, just maybe, =
=93aFoo/a=94.
I later came to the conclusion that this might be a nice thing for HTML =
editors, but not for browsers.=20
If nothing else, it would probably be abused for comment spam, because =
there probably are scripts out there that do not filter =91href=92-less =
=91a=92-elements.
The UA would append the string content, properly encoded, to the base =
Web address as the hyperlink=92s target, =85
=20
I (=85) couldn't find any pages that matched the pattern a =
href=3D(.+)$1/a, =85
Um, that=92s not exactly what I meant, note =93append =85 to the base =
Web address=94.
These are conversions I had in mind, assuming the location =
https://example.com/Bar/baz.html:
derived href value
a hrefFoo/a=3D /Bar/Foo or ./Foo or Foo
a hrefFoo.html/a =3D /Bar/Foo.html or ./Foo.html or =
Foo.html
a hrefFoo.com/a=3D /Bar/Foo.com or ./Foo.com or Foo.com
a hrefFoo//a =3D /Bar/Foo/ or ./Foo/ or Foo/
a href/Foo/a =3D /Foo
a href#Foo/a =3D #Foo
a href//a =3D /
a hrefhttp://Foo.com/a =3D http://foo.com
a href://Foo.com/a =3D https://foo.com (?)=
According to RFC 3986, section 4.2, the first component of a relative
reference can't contain a colon (':'). The last example should be:
a href//Foo.com/a https://foo.com
We don't need to define a new append algorithm, relative [IU]RI
references are powerful enaugh.
Re: [whatwg] Proposal for Web Storage expiration
Is it easier in terms of implementation issues or general consensus? -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: Monday, August 02, 2010 5:51 PM To: Nicholas Zakas Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow Subject: Re: [whatwg] Proposal for Web Storage expiration 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? 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
Re: [whatwg] Please consider dropping the sandbox attribute from the iframe element
On Mon, Aug 2, 2010 at 6:41 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 1, 2010, at 6:59 PM, Tantek Çelik wrote: Summary: The new 'sandbox' feature on iframe should be considered for removal. It needs a security review, it will be a lot of work to implement properly, and may not actually solve the problem it is intending to solve. More details here: http://wiki.whatwg.org/wiki/Iframe_Sandbox I encourage fellow web authors and browser implementers to add their opinions/comments to that wiki page. As other have mentioned, iframe sandbox has been implemented in WebKit for some time. Additional points of information: 1) It's shipping in current versions of Safari and Chrome. 2) Security experts have reviewed it. @sandbox itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and @seamless. 3) Content has been built using it. 4) While it's unclear if iframe sandbox will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like gadgets and ads. While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable. The initial patch implementing it for WebKit can be seen here: http://trac.webkit.org/changeset/51577. This patch was 100k, but more than half of it is tests and the ChangeLog entry. Ian, Adam, Maciej, I very much appreciate the follow-up information you provided regarding this proposal. I've captured it on the WHATWG wiki here: http://wiki.whatwg.org/wiki/Iframe_Sandbox#why_sandbox_should_be_kept The only outstanding requests I have are (on that wiki page) 1. Adam, it would be great if you could write up the summary of all the security discussion - or at least provide links to some of it for further reading. http://wiki.whatwg.org/wiki/Iframe_Sandbox#security 2. Maciej, could you provide a few URLs to content [that] has been built using it. ? http://wiki.whatwg.org/wiki/Iframe_Sandbox#examples_in_the_wild 3. Maciej, could you provide code examples for how sandbox could be used for the use cases you mention of gadgets and ads? http://wiki.whatwg.org/wiki/Iframe_Sandbox#use_cases Thanks much, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] meta=encrypt tag is needed
On Thu, 6 May 2010, juuso_ht...@tele3d.net wrote: meta=encrypt pubkey=ABABAEFEF2626EFEFEF pubtool=EC256-AES|RSA2048-AES passsalt=no|domainname auth=verisign Please try to fully decrypt the above meta-encrypt tag and *see* how the browser-server communication could utilize it. (HINT: browser submits a (session specific) 256bit elliptic curve public key to the server inside every URI-request AND if the target page has meta-encrypt tag, the server uses the browser's elliptic curve key and encrypts the page content with that.) It is very simple, doable and STATELESS. And in html5 it would eliminate some of the biggest real life security threats at the internet. If you *could* learn and instinctly use the above meta-encrypt tag then it should be enough simple for actual usage. What problem is this solving? Please see the WHATWG FAQ for details on how to propose features: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Please consider making summary more generic/flexible (or renaming)
Summary: the new summary element is very generic sounding but has a very special purpose (only allowed inside details). It would be helpful if we made it more generic, in particular allow use of summary inside article body (and perhaps section) to provide general summary text semantics (e.g. this paragraph :), and a potential enhancement to the HTML5-to-Atom conversion algorithm. Alternatively, we could rename summary inside details to something more specific so it won't be confused as a generic-sounding element/feature. More details here: http://wiki.whatwg.org/wiki/Summary I encourage fellow web authors and browser implementers to add their opinions/comments to that wiki page. Thanks! Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
[whatwg] Various forms-related comments
On Thu, 6 May 2010, Schalk Neethling wrote: I absolutely love the fact that browsers will have certain validation baked in like email addresses etc. With that, is there currently a way to, or plans to add a way, where the way the browser displays these errors can be styled with CSS? To a limited extent you can use :invalid and company, but since browsers are still experimenting with how to expose the error messages, there's no standard way to style them yet. Maybe in time, if it makes sense. On Thu, 6 May 2010, Schalk Neethling wrote: Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript? I don't really understand the question. On Thu, 6 May 2010, Tab Atkins Jr. wrote: The purpose of input type=date is to allow the browser to supply the user with a datepicker. If you would like to show a datepicker to users of all browsers, use feature detection (such as through the Modernizr script) to detect whether or not the browser support date inputs, and if not, supply the js version. Indeed. On Fri, 7 May 2010, Schalk Neethling wrote: Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field? My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option? On the long term, the theory is that you'll be able to use XBL to override the rendering and behaviour of these controls, but that's still some way in the future. On Fri, 7 May 2010, Schalk Neethling wrote: Hey TJ, I understand what type=date is supposed to offer the user and agree that using Modernizr to detect whether the element is supported and provide a fallback but my more direct question is, would HTML 5 offer the ability to allow a user to use either the date picker or enter the date manually if the type=date attribute is specified. Something like for example input type=date editable=true / On Fri, 7 May 2010, Tab Atkins Jr. wrote: HTML5 doesn't specify anything about how the date input is presented. It's entirely up to the browser to decide if they want to allow the user to type a date in, or just use a datepicker, or what. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] syncronous device upload
On Sat, 8 May 2010, James Salsman wrote: I propose including the specification at http://www.w3.org/TR/device-upload in HTML5, provided that it is updated to include Speex, Ogg Vorbis, and Ogg Theora. What problem would this solve? As far as I can tell, nothing stops the user agent from offering to record data from any device. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Please consider making summary more generic/flexible (or renaming)
Summary: the new summary element is very generic sounding but has a very special purpose (only allowed inside details). It would be helpful if we made it more generic, in particular allow use of summary inside article body (and perhaps section) to provide general summary text semantics (e.g. this paragraph :), and a potential enhancement to the HTML5-to-Atom conversion algorithm. Alternatively, we could rename summary inside details to something more specific so it won't be confused as a generic-sounding element/feature. In a somewhat related note, following a real-world conversation I had with Jeremy Keith a short while ago, is there a reason why summary (or the theoretical renamed less generic alternative) isn't being used inside figures too, instead of another new element (figcaption)? At the time Jeremy wasn't able to give me an answer, but if it's already been discussed and I just missed it, my apologies. - Andrew
Re: [whatwg] Security thoughts
On Sun, 9 May 2010, Perry Smith wrote: In HTML5 6.3.1 Relaxing The Same Origin Restriction [1] bullet 3, sub bullet 3 there is a clause that says that if the domain is reduced down to something that is on the Public Suffix List, the new value is rejected. That phrase caused me to pause. I was wondering about internal attacks. First, we need to assume a couple of things but they are relatively easy to assume. The first is that the relaxing of the restriction has a valid use. This seems easy or it would not be in the spec. The second is that an internal domain can effectively be a public suffix list to users on the internal intranet. For example, at the place I work, I connect my laptop to the wifi, it grabs an address and also registers the name. Even if the name was not registered, it would still have some DNS entry. The point is that all DNS entries within this subdomain are not trusted. If we have a site like official_site.area_subdomain.big.com which relaxes the restriction to area_subdomain.big.com, it is now exposed to the potential of an attack from any of the systems within the same area_subdomain including laptops connected via wifi. The wifi is secure. The place I work at trusts me to some degree but with a large corporation, they very often try to restrict information on the need to know basis. And, corporate espionage is a real threat. I don't know how common it is for internal corporate sites to relax the same origin restriction but I could see it becoming more and more common as they try to take advantage of various technologies. The corporations could take steps of course to secure the sites. They could put all official web sites in their own subdomain and then relax to this more trusted subdomain. The purposed of this email is to ask if a warning should be added in the 3rd bullet to advise web developers of internal sites to be careful in assuming that all the hosts on their internal subdomain are trusted. I would be happy to add such a warning, but I'm not sure I understand the attack you had in mind. Is this the scenario you have in mind?: User A controls a laptop within Example Corp's firewall and has a host name of laptop1.corp.example.com. User B is also within the firewall. Service V is at service.corp.example.com, and it uses document.domain to relax its same-domain restrictions to example.com. User A tricks User B into visiting a file hosted on his laptop. That file relaxes its same-domain restriction to example.com, loads service V in an iframe, and uses the DOM to perform an attack on V using B's credentials. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Avoiding new globals in HTML5 ECMAScript
On Mon, 10 May 2010, Brett Zamir wrote:
Although it seems a lot of attention has been given to ensuring
backward-compatibility in HTML5, and while a kind of namespacing has
been considered in use of data- attributes (over expando properties), it
appears to my limited observations that global (window) properties are
being added without sufficient regard for backward compatibility (and in
any case limiting future variable naming by authors).
While I can understand the convenience of properties like
window.localStorage or window.JSON, it seems to me that new global
properties and methods (at least future ones!) should be added within
some other reserved object container besides window.
While I can appreciate that some would argue that the convenience of
globals to authors outweighs potential conflict concerns (and I know I'm
not offering this suggestion very early in the process), it seems to me
that HTML5's client-side ECMAScript should model good practices in
limiting itself as far as new globals perhaps similar to how XML
reserved identifiers beginning with xml, doing the same with allowing
one W3C global or maybe HTML{N} globals or the like (HTML alone
would no doubt be way too likely to conflict), allowing authors the
assurance that they can name their properties freely within a given set
of constraints without fear of being over-ridden later.
I agree with you in principle, but there are three other factors to bear
in mind:
1. When we add something in the global namespace, we do get to test to see
if it breaks anything before making it final. It's not like we're just
adding things willy-nilly.
2. Other namespaces tend to be just as problematic. For example, we've run
into problems adding attributes to elements, even though there's really
no reason anyone should be doing anything there.
3. If we can add to the global namespace without conflicts, it's
preferably to other options because it's much more convenient and
memorable.
These, as well as everything you say, are all taken into account when we
add new DOM APIs.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementById
On Mon, 10 May 2010, Perry Smith wrote:
I see places that explicitly state that the same object is returned on
some operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is
referenced an explicit statement to this effect for getElementById.
getElementById() is a DOM Core method, so not defined by the HTML spec.
However, the DOM spec says it returns the Element, so that seems to
require that the same Element object representing the element be returned.
In practice there is always only one object per element anyway.
The other part to this that is not explicitly mentioned is if I attach a
new javascript attribute to the object, is that legal? Is it defined to
work? I have not found a statement one way or the other.
e.g.
foo = getElementById('foo');
foo.newAttr = true;
/* later */
foo = getElementById('foo');
if (foo.newAttr) {
alert(happy happy joy joy);
}
This would be defined by WebIDL.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] getContext multiple contexts
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? I don't have a problem with this simplification. It essentially allows for multiple contexts but adds no synchronization primitives other than the requirement that rendering must be visible to all contexts (that is, that they're rendered to the same destination space). Having 3D and 2D contexts rendering to the same space -- especially given getImageData() and the like -- seems like an interoperability nightmare. I agree. This also adds the 'attributes' parameter which can customize the context that's created, as defined by the context itself. WebGL has its own context attributes object, and I'd suggest that the 2D context gain at least an attribute to specify whether the context should be opaque or not; but that's a separate suggestion from the below text. I haven't added this. Could you elaborate on why this is needed? What happens if the method is invoked agains with different parameters? It seems far preferable to have this on the API rather than as part of the getContext() method. 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. - ~Chris cmar...@apple.com
Re: [whatwg] suggestion for HTML5 spec
On Aug 2, 2010, at 7:20 PM, Dirk Pranke wrote: On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. This seems like a matter for the user, not the Web page, though. Ah, I knew you were going to say this. I agree, but I can also imagine that the way the user selects this is by choosing one of two different resources from a page, just like we do today for videos of different bandwidths. It seems better to have a way for the user agent to automaically negotiate the right bandwidth usage based on user preference, too. Any setting like this that we offer authors _will_ be misused, possibly as often as used correctly. Unless there's a really compelling reason to have it, it seems better to let the user be in control. If users can choose between two links on a page labelled high FPS - will destroy your battery and low FPS, they are in control, in a way that is easily understood by the user and allows them to make the choice at the point in time that it matters. Compare this with changing the streaming settings on QT Player or Windows Media Player, or even toggling the use the video card button on your laptop (and hoping that the content is smart enough to degrade gracefully instead of choking). But an author can't make that claim if it involves forcing the GPU on or off. If we were to do this, I'm sure there would be implementations where the exact opposite of the author's intent would be the result. Saying something like turn off the GPU can result in more or less battery usage, depending on the hardware, software and content. Preserving battery life should be the job of the system (possibly with I care more about battery life than quality input from the User Agent). We've seen this exact same argument play out over the last fifteen years in video on the web. The technology for detecting and adjusting bandwidth dynamically has been around forever (actually implemented, even), and yet for every one multi-bitrate stream available on the web, I imagine there are very many more that are single-bitrate. A big part of the reason for this is because doing it this way is (in my opinion) a better user experience. Sure, you might be able to say that a lower bitrate video will use less power than a higher bitrate one. So the author might want to provide two videos. But leave it up to the system to decide what hardware to use to play them. - ~Chris cmar...@apple.com
Re: [whatwg] [canvas] getContext multiple contexts
On Aug 3, 2010, at 3:15 PM, 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? I don't have a problem with this simplification. Sorry, in rereading this I realize that the last statement is confusing. I don't have a problem with hixie's simplification on when to fail getContext. The string passed for a WebGL context should be 'webgl', not '3d'. - ~Chris cmar...@apple.com
Re: [whatwg] [canvas] getContext multiple contexts
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.) [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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Paragraphs in blockquotes
On Tue, 11 May 2010, Richard Clark wrote: We recently received an email from one of our readers on html5doctor.com that went like this: Hi, in HTML 4.0 Strict XHTML 1.0 Strict, text inside a blockquote element is required to be nested inside another block-level element, e.g. p. In HTML5 that requirement seems to have been relaxed, as the following element validates successfully: blockquoteThis is a blockquote./blockquote The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required. Can you please confirm if this requirement has now been deprecated? We tested the below which successfully validated: !doctype html meta charset=utf-8 titleblockquote test/title blockquoteTiger tiger burning bright/blockquote So the question is, are block level elements required in blockquotes or can the p's be removed from the examples in the spec? On Tue, 11 May 2010, Masataka Yakura wrote: blockquote can take any flow content [...] So in HTML5 blockquote doesn't require inline contents to be nested inside another block elements (you may know but that was acceptable too in HTML4 Transitional). On Tue, 11 May 2010, Futomi Hatano wrote: The content model for blockquote is Flow content. Flow content includes text. So, the text as a child of blockquote is valid. The spec says that a run of phrasing content (in this case, it is the text.) is a paragraph. http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#paragraph So, the examples below have same semantics. blockquoteThis is a blockquote./blockquote blockquotepThis is a blockquote./p/blockquote The former is valid, but, of course, authers are encouraged the latter much more. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Race condition in media load algorithm
On 3/08/2010 9:20 a.m., Ian Hickson wrote: The synchronous section would run as soon as the task span the event loop. Spinning the event loop is defined essentially as being equivalent to breaking the original task in two, one that does everything up to spinning the event loop, and one that does everything after spinning the event loop. You are effectively waiting for some condition to become true and then queueing a task to run the continuation of the algorithm. It's just more convenient to write the algorithms as one long set of steps rather than having split them up into multiple algorithms that invoke each other and pass state around. Or does stop the currently running task in #spin-the-event-loop imply a jump to step 2 of the algorithm under #processing-model2? Yes. So the task spinning the event loop has run up to the point of spinning the event loop, then we run the synchronous section, and then the task which was spinning the event loop will resume after its goal is met at some later time? In the case of a tasks which invokes an algorithm which has a synchronous section, and then pauses the event loop (such calling window.alert()), we should not run the synchronous section until the event loop pause has completed? Thanks, Chris Pearce.
Re: [whatwg] Race condition in media load algorithm
On Wed, 4 Aug 2010, Chris Pearce wrote: So the task spinning the event loop has run up to the point of spinning the event loop, then we run the synchronous section, and then the task which was spinning the event loop will resume after its goal is met at some later time? Sounds right. In the case of a tasks which invokes an algorithm which has a synchronous section, and then pauses the event loop (such calling window.alert()), we should not run the synchronous section until the event loop pause has completed? Currently, yeah. We might want to make pause also trigger synchronous sections, if that's a problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] A ui Tag?
On Wed, 12 May 2010, Darcy Murphy wrote (on help@): Recently I came up with the idea of using a ui tag in order to semantically separate my app's content from it's UI chrome. I could use form but then even clicking a simple button submits the form's data when what I'm creating is more of a stateful toolbar than a proper form. (Note that you can work around that last problem by saying form action=javascript:void(0), at least according to the spec.) To that end, is there something like ui already available, or in the works, or a better solution that I'm not aware of? I'm not clear on what you consider content vs chrome, so it's hard to really comment, but in general the section and article elements are available for this kind of thing. If you have a concrete example it would be easier to say whether the spec needs new elements to handle it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The form attribute (Association of controls and forms)
On Fri, 14 May 2010, Mounir Lamouri wrote: 4.10.18 Association of controls and forms explains the link between forms and form-associated elements (and the form attribute). However, I've the feeling the specifications go far over what should be done and force the implementor how to do it. What I mean is, this could be summarized like this: If the form attribute is specified, the form owner of the element is the first form in the Document with the id corresponding of the form attribute value, if any. If the form attribute content is not a form element id, the element has no form owner. If the form attribute isn't specificed, the element form owner is the nearest ancestor form. However, the specification say (not only): When a form-associated element's ancestor chain changes, e.g. because it or one of its ancestors was inserted or removed from a Document, then the user agent must reset the form owner of that element. When a form-associated element's form attribute is added, removed, or has its value changed, then the user agent must reset the form owner of that element. When a form-associated element has a form attribute and the ID of any of the elements in the Document changes, then the user agent must reset the form owner of that form-associated element. When a form-associated element has a form attribute and an element with an ID is inserted into or removed from the Document, then the user agent must reset the form owner of that form-associated element. These sentences explain more than what should be the form owner but explain how to implement it. It seems useless and maybe not needed sometimes (I'm wondering if checking for the ID wouldn't be better than observing all the element's ID change and insertion/removal). In my opinion, the form attribute behaves more or less like the for attribute for the label element so I'm wondering why the specification is so different. Is there a reason I'm missing ? This is unfortunately needed for historical reasons. It handles weird cases like: divform/div input ...where the input or the form are later moved in the DOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Offline web applications file upload
On Fri, 14 May 2010, Alexandre Thiel wrote: I was wondering if HTML5 Offline mode and file upload can work together ? I can't find any reference in the online draft which covers only server resource caching. Let's imagine you're writing some kind of data editor that works in offline mode, can you ask the user to select a file to import from his filesystem that can be processed with javascript or directly transfered to the localStorage while being offline ? Yes, using the input.files attribute and then storing the result in localStorage. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element-related feedback; attribution element
On Fri, 14 May 2010, Jim Jewett wrote: Evil Lawyer: So, when did you stop beating your wife? Defendant: Never! Evil Lawyer and Defendant aren't pronounced. Their meanings (and silence) are deduced from English conventions about punctuation. I would prefer a semantic tag. Why? What problem would a semantic tag solve? The default styling here seems to not need any particular element; the above is perfectly understandable as is as far as I can tell. For written output, yes, the convention works. Ideally, a screen reader should *not* read the attribution labels -- but it should use them to switch voices. You can in theory do that today using classes and Speech CSS. Do people do it? If not, it's not clear that there's enough demand to add this yet. I'm expecting [scripts] to do something like increase the font size or change the background for lines *I* have to memorize for *my* character [based on the semantic marked in the page identifying the character], or for cue lines that I have to recognize. Are there any examples of this in the wild? Since this is technically possible today, if it's a use case important enough that we should address it, it should be easy enough to find examples of this. I'm very reluctant to provide features for hypothetical problems that don't stem from a real market need. (If we start solving such problems, we would fast find ourselves on the path to feature bloat.) I haven't acted much since finding the internet. I have seen plenty of printed scripts in which this was done manually with a highlighter for rehearsals. I would expect today's equivalent to be done at time of printing, rather than by a helpful web site. Highlighting someone's lines can be done using mark. So the need is there; the question is whether the need is too specialized (like the various poetry elements) ... if the only use were scripts, I would say that it was too specialized, but I would also use it for photo credits (the italicized captions), etc. Whether that then makes it too much of a catchall element -- maybe. Credit for a photograph and the name of the speaker in a script seem like wildly different use cases with very little, if any, overlap. I don't think it makes sense to consider them together. I would expect it to be used by some scrapers looking for stock photos. I'm not sure what you mean. Wouldn't fingerprinting the photos be more effective? I was thinking of scrapers acting on behalf of a consumer -- collecting a bunch of photos that you would be allowed to use. This is a mostly solved problem today -- sites like Flickr and Google Image Search provide license filters in their search tools. Plenty of model and photographer websites are largely devoted to finding each other; I assume that this is because photographers are looking to find (and then contact) models with a particular look, while models are looking to be photographed by photographers skilled in a certain style. Again, this seems like a fairly specialized need, but I've seen in on several sites, and it again gets met by an attribution or credits element. This seems like an incredibly specialised need that is best solved by special-purpose databases and tools than by the Web's markup language. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Java language bindings for HTML5
On Mon, 17 May 2010, Kühn Wolfgang wrote: I was wondering if there are any precompiled Java language bindings for HTML5? There's nothing official; hopefully the links provided by other people on this thread are helpful though. As it is, i can't figure package names, for example for the WebSocket API. According the WebIDL specs, it should be org.w3c.WebSocket, right? As for the html5 elements, will there be a new package org.w3c.dom.html5? All the DOM stuff should end up in the same package, but I'm not sure what that is. That's probably binding-specific. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Race condition in media load algorithm
On 4/08/2010 11:32 a.m., Ian Hickson wrote: In the case of a tasks which invokes an algorithm which has a synchronous section, and then pauses the event loop (such calling window.alert()), we should not run the synchronous section until the event loop pause has completed? Currently, yeah. We might want to make pause also trigger synchronous sections, if that's a problem. Having pause trigger synchronous sections is definitely easier for us to implement, and would make pausing the event loop consistent with spinning the event loop WRT synchronous sections. Chris P.
Re: [whatwg] Window events that bubble?
On Mon, 17 May 2010, David Flanagan wrote: Section 6.5.9 History Traversal defines popstate and hashchange events that are fired on the Window object. It specifies that these events *must* bubble. Where should they bubble to? What does it mean to bubble up from a Window? These events aren't going across frames, are they? Is the specification that they must bubble a formality because existing implementations set the bubbles property of the Event object to true? Or does it actually have some impact on event propagation? On Mon, 17 May 2010, Jonas Sicking wrote: My understanding is that the only noticable effect of defining that these effects bubble is that their bubbles property is set to true. Same thing happens to bubbling events fired at an XMLHttpRequest object. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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?
Isn't interactive content not important enaugh? What about text? What if
one want's to link to interactive maps? s...@src? a class=embed..
with .embed {content: url(attr(href)) }? AFAIK CSS doesn't support it,
and if it does a rel=embed.. could be used as well, even without
explicit browser support.
Also someone wrote that one should use object for media-types that
aren't supported in HTML yet. If you insist on keeping video and
audio, think of this as a way for second-class media-types WHATWG
hasn't approved/haven't been implemented to use some of the features of
video and audio.
I don't understand these paragraphs at all.
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.
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.
I didn't really follow the rest of your e-mail. It would be helpful if you
could construct your feedback in the form of a problem faced by users,
rather than in the form of a proposed solution. This would enable the
proposal to be properly evaluated.
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?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Built-in image sprite support in HTML5
On Fri, 21 May 2010, David Weitzman wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. I think the right solution is a fragment identifier. On Sat, 22 May 2010, Silvia Pfeiffer wrote: On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The Media Fragments WG has a draft spec out for, well, Media Fragments, which let you specify which section of an image you want right in the url. �The browser should then automatically cut it out and serve just the sprite you want. Yes, I was going to suggest that spec, too, see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. I would recommend fixing that. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTML resource packages
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/ and the bug (complete with builds you can try and some preliminary performance numbers) is here: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 You can think of resource packages as image spriting 2.0. A page indicates in its html element that it uses one or more resource packages (which are just zip files). Then when that page requests a resource (be it an image, a css file, a script, or whatever), the browser first checks whether one of the packages contains the requested resource. If so, the browser uses the resource out of the package instead of making a separate HTTP request for the resource. There's of course more detail than that, of course. Hopefully it's (mostly) clear in the spec. I envision two classes of users of resource packages. I'll call the first resource-constrained developers. These developers care about how fast their page is (who doesn't?), but can't spend weeks speeding up their page. For these developers, resource packages are an easy way to make their pages faster without going through the pain of spriting their images and packaging their js/css. The other class of users are the resource-unconstrained developers; think Google or Facebook. These developers have already put a huge amount of effort into making their pages fast, and a naive application of resource packages is unlikely to make them any faster. But these developers may be able to use resource packages cleverly to gain speedups. In particular, nobody (to my knowledge) currently sprites content images, such as the results of an image search. A determined set of developers should be able to construct resource packages for image search results on the fly and save some HTTP requests. So we can avoid rehashing here the common objections to resource packages, here's a brief overview of the arguments I've heard against the feature and my responses. * Argument: Packaging isn't the way forward. When you change one resource in a package you have to change the whole package and so the user has to re-download all the bits when most of what was in their cache would have been fine. This is of course correct, but we don't think it eliminates the utility of resource packages. The resource-constrained developer is probably happy with anything which speeds up page loads, even if it's not optimal when one part of the page changes. And the resource-unconstrained developer probably won't find resource packages too useful for non-dynamic content, so caching isn't an issue in that case. * Argument: We can already package things pretty well. Mozilla should instead be focusing on improving caching (or something else). I'd contend that we don't package particularly well in general. The Facebook homepage loads 100 separate resources on a cold cache, and they certainly care about speed. But anyway, this is just one project. We're also looking at caching. :) * Argument: Isn't this subsumed by HTTP pipelining? Mostly. But we can't turn on HTTP pipelining because transparent proxies break it. Resource packages have the further benefit that they allow page authors to explicitly set the order in which the UA will download the resources -- with pipelining, an important resource might get stuck behind a large, unimportant resource, while with resource packages, the UA always downloads resources in the order they appear in the zip file. Last, my understanding is that the HTTP pipeline isn't particularly deep, so perhaps resource packages fill the TCP pipe better on high-latency connections. I haven't looked into this, though. * Argument: What about SPDY? I think SPDY should subsume resource packages. But its deployment will require changes to both web clients and servers, so it will probably take a while after it's released before it's available on all web servers. And we have no idea when to expect SPDY to be ready for production. Resource packages, in contrast, are something we can have Right Now. Additionally, since resource packages are backwards-compatible -- a page which specifies resource packages should display just fine in a browser which doesn't support them -- we should be able to turn off resource packages in the future if we decide we don't want them anymore. We'd love to hear what you think of the specification and our implementation. -Justin
Re: [whatwg] CSS2 system colors in legacy color values
On Sat, 22 May 2010, L. David Baron wrote: The rules for parsing a legacy color value in http://www.whatwg.org/specs/web-apps/current-work/complete/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value specify that CSS2 system colors should be accepted, and that they should be converted to a simple color. It seems like a substantial amount of work to get dynamic change handling correct for this case, since system colors can change dynamically when the user changes system appearance. I'd really like to avoid having to add dynamic change handling for this, and I'd also like to avoid having to make system colors dynamic in CSS but static in HTML. What was the motivation for adding support for CSS2 system colors (which I would note are deprecated in css3-color) to legacy HTML color values? On Sun, 23 May 2010, Simon Pieters wrote: IE compat. On Sat, 22 May 2010, L. David Baron wrote: What implementations support them... On Sun, 23 May 2010, Simon Pieters wrote: I think WebKit and IE. On Sat, 22 May 2010, L. David Baron wrote: and do they respond to dynamic changes properly? WebKit on Mac responds to changes to the color Highlight by changing the colour to the default blue the next time it resolves style (as far as I can tell). Not exactly a success story. (Highlight is the only colour over which the user seems to have control on Mac.) IE8 on Windows XP apparently updates automatically (thanks to wirepair on #whatwg for testing that). On Sun, 23 May 2010, Simon Pieters wrote: It appears that Opera and Gecko don't support system colors. I wouldn't mind not supporting them, but it could be interesting to research how many pages it affects. I don't have such research, unfortunately. I've removed the support for it for now. On Mon, 31 May 2010, Roger Hågensen wrote: I'm kinda surprised that there is no support for floating point colors though. Althought I guess that rgb(x%, x%, x%) An RGB percentage value (e.g. rgb(100%,0%,0%)) is as close as you get to that... Does percentage rgb color support things like 85.41% though? I hope so as only rgb(x%, x%, x%) is tentatively gamut independent. The legacy color values are just that, legacy, the less we support there the better. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML resource packages
On Tue, Aug 3, 2010 at 5:31 PM, 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/ and the bug (complete with builds you can try and some preliminary performance numbers) is here: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 [snip] We'd love to hear what you think of the specification and our implementation. I love it! You guys seem to have hit all the big points while sidestepping the obvious problems. Resource packages as Sprites 2.0 makes me very, very happy (and also more confident about removing any attempt at a spriting solution from CSS - it's the wrong layer). ~TJ
Re: [whatwg] Questions about the progress element
On Mon, 24 May 2010, Mounir Lamouri wrote: I'm wondering why the value and max IDL attributes have to reflect the content attribute with zero as a default value instead of reflecting the internal values used to calculate the position. Wouldn't that be easier to know what is the internal value and max values by using the IDL attributes ? I've changed 'max' to default to 1 rather than 0, but in general I think we should avoid having magic in IDL attributes that reflect content attributes, as it leads to very strange behaviour. In addition, couldn't the position IDL attribute returns a double instead of a float? As we are dividing two floats, the precision may be helpful. I don't really mind; what do implementors think makes most sense here? 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. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] CSS2 system colors in legacy color values
On Aug 3, 2010, at 5:55 PM, Ian Hickson wrote: WebKit on Mac responds to changes to the color Highlight by changing the colour to the default blue the next time it resolves style (as far as I can tell). Not exactly a success story. (Highlight is the only colour over which the user seems to have control on Mac.) I just tested this and it works perfectly. When I change the Highlight color using the Appearance pane of the Mac OS X System Preferences the color of highlighted text in Safari is immediately the right color as soon as I switch back to Safari. Your comment, “[WebKit changes] the colour to the default blue the next time it resolves style” makes it sound like the code doesn’t work, but it works well and it is a success story! -- Darin
Re: [whatwg] CSS2 system colors in legacy color values
On Tue, 3 Aug 2010, Darin Adler wrote: On Aug 3, 2010, at 5:55 PM, Ian Hickson wrote: WebKit on Mac responds to changes to the color Highlight by changing the colour to the default blue the next time it resolves style (as far as I can tell). Not exactly a success story. (Highlight is the only colour over which the user seems to have control on Mac.) I just tested this and it works perfectly. When I change the Highlight color using the Appearance pane of the Mac OS X System Preferences the color of highlighted text in Safari is immediately the right color as soon as I switch back to Safari. Your comment, “[WebKit changes] the colour to the default blue the next time it resolves style” makes it sound like the code doesn’t work, but it works well and it is a success story! We're talking about body bgcolor=Highlight here, not about the colour of selected text. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Built-in image sprite support in HTML5
On Wed, Aug 4, 2010 at 10:19 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 21 May 2010, David Weitzman wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. I think the right solution is a fragment identifier. On Sat, 22 May 2010, Silvia Pfeiffer wrote: On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The Media Fragments WG has a draft spec out for, well, Media Fragments, which let you specify which section of an image you want right in the url. The browser should then automatically cut it out and serve just the sprite you want. Yes, I was going to suggest that spec, too, see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. I would recommend fixing that. :-) Well, that goes into implementation issues and really has nothing to do with the URI specification itself. The media fragment URI specification can propose what is possible to happen for representing a media fragment URI and it does so by now: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-display. But really, the application has to decide for itself what makes sense. As we adopt media fragment URIs into the HTML5 spec, we should prescribe what the user experience is meant to be, such that UAs can implement a consistent handling. Cheers, Silvia.
Re: [whatwg] HTML resource packages
This is and was a great idea. A few points/questions: 1) I think it would be nice to see explicit confirmation in the spec that this works with offline caching. 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. 4) Could such a protocol also be made to accommodate profiles of packages, e.g., by a namespace being allowable somewhere for each package? Thus, if a package is specified as say being under the XProc (XML Pipelining) namespace profile, the browser would know it could confidently look for a manifest file with a given name and act accordingly if the profile were eventually formalized through future specifications or implemented by general purpose scripting libraries or browser extensions, etc. Another example would be if a file packaging format were referenced by a page, allowing, along with a set of files, a manifest format like METS to be specified and downloaded, describing a sitemap for a package of files (perhaps to be added immediately to the user's IndexedDB database, navigated Gopher-like, etc.) and then made navigable online or offline if the files were included in the zip, thus allowing a single HTTP request to download a whole site (e.g., if a site offered a collection of books). And manifest files might be made to specify which files should be updated at a specific time independently of the package (e.g., checking periodically for an updated manifest file outside of a zip which could point to newer versions). Note: the above is not asking browsers to implement any such additional complex functionality here and now; rather, it is just to allow for the possibility of automated discovery of package files having a particular structure (e.g., with specifically named manifest files to indicate how to interpret the package contents) by providing a programmatically accessible namespace for each package which could be unique per application and interpreted in particular ways, including by general purpose JavaScript libraries. This is not talking about adding namespaces to HTML itself, but rather for specifying package profiles. Such extensibility would, as far as I can see it, allow for some very powerful declarative styles of programming in relation to handling of multiple files (whether resource files, data files, or complete pages), while piggybacking on the proposal's ability to minimize the HTTP requests needed to get them. best wishes, Brett On 8/4/2010 8:31 AM, Justin Lebar 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/ and the bug (complete with builds you can try and some preliminary performance numbers) is here: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 You can think of resource packages as image spriting 2.0. A page indicates in itshtml element that it uses one or more resource packages (which are just zip files). Then when that page requests a resource (be it an image, a css file, a script, or whatever), the browser first checks whether one of the packages contains the requested resource. If so, the browser uses the resource out of the package instead of making a separate HTTP request for the resource. There's of course more detail than that, of course. Hopefully it's (mostly) clear in the spec. I envision two classes of users of resource packages. I'll call the first resource-constrained developers. These developers care about how fast their page is (who doesn't?), but can't spend weeks speeding up their page. For these developers, resource packages are an easy way to make their pages faster without going through the pain of spriting their images and packaging their js/css. The other class of users are the resource-unconstrained developers; think Google or Facebook. These developers have already put a huge amount of effort into making their pages fast, and a naive application of resource packages is unlikely to make them any faster. But these developers may be able to use resource packages cleverly to gain speedups. In particular, nobody (to my knowledge) currently sprites content images, such as the results of an image search. A determined set of developers should be able to construct resource packages for image search results on the fly and save some HTTP requests. So we can avoid rehashing here the common objections to resource packages, here's a brief overview of the arguments I've
Re: [whatwg] suggestion for HTML5 spec
On Tue, Aug 3, 2010 at 3:22 PM, Chris Marrin cmar...@apple.com wrote: On Aug 2, 2010, at 7:20 PM, Dirk Pranke wrote: On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. This seems like a matter for the user, not the Web page, though. Ah, I knew you were going to say this. I agree, but I can also imagine that the way the user selects this is by choosing one of two different resources from a page, just like we do today for videos of different bandwidths. It seems better to have a way for the user agent to automaically negotiate the right bandwidth usage based on user preference, too. Any setting like this that we offer authors _will_ be misused, possibly as often as used correctly. Unless there's a really compelling reason to have it, it seems better to let the user be in control. If users can choose between two links on a page labelled high FPS - will destroy your battery and low FPS, they are in control, in a way that is easily understood by the user and allows them to make the choice at the point in time that it matters. Compare this with changing the streaming settings on QT Player or Windows Media Player, or even toggling the use the video card button on your laptop (and hoping that the content is smart enough to degrade gracefully instead of choking). But an author can't make that claim if it involves forcing the GPU on or off. If we were to do this, I'm sure there would be implementations where the exact opposite of the author's intent would be the result. Saying something like turn off the GPU can result in more or less battery usage, depending on the hardware, software and content. Preserving battery life should be the job of the system (possibly with I care more about battery life than quality input from the User Agent). I think you're probably right that different systems can have different performance profiles and you can't design a one size fits all solution here. Perhaps instead of enable GPU / disable GPU you need high complexity / low complexity as a hint to the user agent. We've seen this exact same argument play out over the last fifteen years in video on the web. The technology for detecting and adjusting bandwidth dynamically has been around forever (actually implemented, even), and yet for every one multi-bitrate stream available on the web, I imagine there are very many more that are single-bitrate. A big part of the reason for this is because doing it this way is (in my opinion) a better user experience. Sure, you might be able to say that a lower bitrate video will use less power than a higher bitrate one. So the author might want to provide two videos. But leave it up to the system to decide what hardware to use to play them. Of course, you can also imagine a lower bitrate stream using more power than a higher bitrate run (VP8 may be more efficient than MPEG-2, but can't be decoded in hardware and hence is far more expensive). Perhaps all this illustrates is that the problem is far from simple and so no simple API is likely to be that helpful. I'm not sure ... -- Dirk
Re: [whatwg] HTML resource packages
On Aug 3, 2010, at 5:31 PM, Justin Lebar 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/ and the bug (complete with builds you can try and some preliminary performance numbers) is here: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 Have you done any performance testing of this feature, and if so can you share any of that data? I'm particularly interested in: * Effect of using a resource package on page-load time, in the initial fully uncached case. * Effect of using a resource package on page-load time, in the case where the resources in the package have expired but not have changed. * Effect of using a resource package on page-load time, in the case where the resources in the package have expired and a subset of them have changed. (This could still be a win for packages.) * Effect of using a resource package on page-load time, in the case where everything in the package is cached. These are probably most interesting under high-latency network conditions (real or simulated). You address these points qualitatively in your comments but I'd love to see some numbers. That would make it easier to evaluate the performance tradeoffs. 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? In general I am in favor of features that can improve page load times and which are Cheers, Maciej
