Re: [whatwg] header for JSON-LD ???
On Tue, Jul 25, 2017 at 2:21 PM Michael A. Peters <mpet...@domblogger.net> wrote: > On 07/25/2017 10:45 AM, Jonathan Zuckerman wrote: > > This suggestion might have more success with the W3C? I'm not completely > > clear on the politics and history of the two orgs, but it seems like the > > W3C has supported JSON-LD in the past, so they might have some interest > in > > expanding it. > > > > On a personal note, I think you've got really far down the path of a > hammer > > looking for a nail. Spend more time working with the web you've got > before > > trying to change it. > > Fuck you. Seriously. I've been working with the web since the late 90s. > > I don't need condensing crap like that. > > [...] > > I'm sorry you are too biased against it to open your mind and see it. > > Learn some fucking manners. > Disrespect of fellow members of the list is unacceptable. Michael has been banned from the list for two weeks. Please peruse our code of conduct if the reasoning behind this action is unclear to you: https://whatwg.org/code-of-conduct Thanks. -- -- Ian Hickson
Re: [whatwg] Accessing local files with JavaScript portably and securely
On Tue, Apr 18, 2017 at 3:36 PM Richard Maher <maher...@hotmail.com> wrote: > > The main thing that seems to be missing from this thread is any > commitment > > from any browser vendors to actually support any changes in this space. > > It has been my experience that browser vendors, more often than not, > require at least a (proposed) standard before they will consider > implementing a requested feature. > That's a different question. I was saying we should make sure the browser vendors care about this space at all. Requesting a specific feature be implemented comes much later, after use case collection and API design stages. If the browser vendors feel like this is out of scope for their product, then spending the (quite extensive) effort to design a solution will be wasted. I wouldn't want anyone on this list to feel their time is wasted. I would certainly not seek to stifle debate or censor someone else from > having their say. > Indeed not! I should hope nobody would feel that way. The WHATWG is a venue that is open to anyone willing to take part in relevant technical debate. -- -- Ian Hickson
Re: [whatwg] Accessing local files with JavaScript portably and securely
The main thing that seems to be missing from this thread is any commitment from any browser vendors to actually support any changes in this space. I would recommend the following steps for anyone hoping to push changes to Web specifications on this topic: - Approach Web browser vendors privately, to see if they are interested in changing their behaviour in this space. - If you find interest, collect up the use cases that you want to address, and post them to this list for discussion. - Collect the input on use cases and try to design a solution that fits all the important use cases, then send an an e-mail to this list proposing a basic design. Cheers, -- Ian Hickson -- -- Ian Hickson
[whatwg] window.opener security issues (Was: WhatWG is broken)
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters <mpet...@domblogger.net> wrote: > > Right now the specification for window.opener() is seriously insecure, > allowing for cross-domain script access by default. > I believe that's a bit of an overstatement. There are certainly risks involved in window.opener (they're briefly discussed in the spec itself), but it doesn't remove the origin checks. > The reason they refuse to properly address the issue is because it would > break OAuth. > I'm not sure who "they" is here, but since this is the first this topic has come up on this list, would you mind providing us with some background? For example, could you describe the security risk? How does it break OAuth? Can you give an example of a page affected by this? If there's a particular github issue where these topics have already been discussed, then if you would like the broader WHATWG community to be aware of these issues then I recommend linking to that issue in your e-mail to the list. Many people following the list don't follow the github repository closely enough to see every issue. the browsers will not protect them unless the specification calls for it, > and the specification will not call for it because the same companies > that are heavily invested in OAuth run the WhatWG. > That's not really how the WHATWG works. I encourage you to read our FAQ: https://wiki.whatwg.org/wiki/FAQ One factor to bear in mind in particular is that the specification has no power. We could put whatever we want in the spec, but if browser vendors don't want to implement it, it doesn't really matter, they'll just ignore it. If the WhatWG can't put the security of Internet users first, then it > needs to be disbanded and replaced by a working group that will put the > security of the users first. > There's already plenty too many working groups working on HTML as it is... Cheers, -- Ian Hickson
Re: [whatwg] Intent to implement: Background Geolocation for Progressive Web-Apps
Richard, The WHATWG mailing list is actually not an appropriate place for either this kind of e-mail (I'm not even really sure what this e-mail was supposed to be... are you an implementor?) nor your other recent e-mail (voting for a feature doesn't help in the WHATWG, all that matters is the quality of arguments and data presented). I urge you to read the WHATWG FAQ before sending further e-mails to the list. Thanks. https://wiki.whatwg.org/wiki/FAQ If you wish to respond to this e-mail please do not cc the WHATWG list in your reply. Cheers, -- Ian Hickson On Tue, Nov 29, 2016 at 11:46 PM Richard Maher <mahe...@googlemail.com> wrote: Contact emails mahe...@gmail.com *Summary* Secure, user-sanctioned geolocation collection is currently unavailable for HTML5 Web-Apps when they are not running or in the foreground. This leaves the browser hosted applications incapable of competing with Native Apps on an even playing field. The main goal of background geolocation reporting is to all web-apps, but in particular, Gaming, Social-Network, and Fleet-Management Apps, to continue to function even if the device has gone to sleep or another App is in the foreground. Additional goals are: - Power-Saving. By using the existing ServiceWorker paradigm and flexible throttle/filter on which geolocation movements are "interesting". - Single-process (Google Play etc) to monitor all geolocation reports for all Apps before deciding if ServiceWorker(s) need to be instantiated. - Unlike Mozilla's current implementation, stalkers, estranged spouses, and marketeers will no longer be allowed to track users covertly. Here is design overview document: https://sites.google.com/a/chromium.org/dev/developers/design-documents/ ServiceWorker/TravelManagerEvent < https://www.google.com/url?q=https%3A%2F%2Fsites.google.com%2Fa%2Fchromium.org%2Fdev%2Fdevelopers%2Fdesign-documents%2Fsync%2Funified-sync-and-storage-overview=D=1=AFQjCNHwnrvcFIOorADSVqVKlLO-C3dOcQ > Ongoing technical constraints None. See https://w3c.github.io/ServiceWorker/#extensibility Tracking bug There is currently no top level bug. *FOR MORE PLEASE SEE: - * https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/kDq4t93zbpA
Re: [whatwg] Proposal for showing thousand separator in form controls.
On Thu, 15 Oct 2015, Михаил Гаврилов wrote: > > Frankly I do not understand it means, yes or no? > I am first time here. > How did approval procedure takes place? > Anything else I need to do or describe final idea? Any examples how > make this better. You may find more details about how things work here in our FAQ: https://whatwg.org/faq HTH. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] XML/HTML Entities draft
On Fri, 2 Oct 2015, David Carlisle wrote: > > Ian, > Not sure if you still use a "live" copy of unicode.xml > and hopefully there will never be a need to change the > HTML character entity definitions but anyway > > > The editor's draft of the entities spec has been moved to github > > > > https://w3c.github.io/xml-entities/ > > > > (The old URL at http://www.w3.org/2003/entities/2007doc/ redirects to the > > same thing) > > > > In particular this now means that unicode.xml and other source files > > are more easily tracked by other projects. (I know several browser > > and latex-to-xxx projects are using that in one way or another.) > > > > The sources are at > > > > https://github.com/w3c/xml-entities Thanks for the heads-up, David! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] W3C Timed Text Working Group proposal for HTMLCue
On Thu, 10 Sep 2015, Nigel Megitt wrote: > >On Thu, 10 Sep 2015, Nigel Megitt wrote: > >> > >> We think an HTML cue as a variant of the third option is the best > >> solution. > > > >If you do this please make sure to define in detail how it should all > >work. > > Are you commenting that it is not a bad proposal in principle, given > extra detail, or that it is not a proposal that can be assessed at all > with the current level of detail? More the latter. I do think the work involved would be quite substantial. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] W3C Timed Text Working Group proposal for HTMLCue
(Please don't cross-post to the WHATWG list -- either post to the WHATWG list, or post to other lists, but not both at the same time. It causes threads to fragment as people aren't on all the lists.) On Thu, 10 Sep 2015, Nigel Megitt wrote: > > We think an HTML cue as a variant of the third option is the best > solution. If you do this please make sure to define in detail how it should all work. For example, what happens if a script running inside a cue does "history.back()"? What happens if an auto-playing video element in a cue is given a URL that points to a resource that requires HTTP authentication? Is each cue a separate Document? What happens to media queries in a cue? These questions are but the tip of a very, very large iceberg. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] deprecating
On Fri, 4 Sep 2015, henry.st...@bblfish.net wrote: > > [...] Since this topic is a potential security flaw in shipping software, I think it's probably unwise and irresponsible to be discussing the details in a public forum. I'm sorry I sound like I keep trying to shut down this thread. I'm really not trying to do that specifically. This thread just keeps accidentally entering into the kinds of areas that we try to keep off the WHATWG list, to wit, non-technical arguments, arguments about other groups' specifications, arguments about implementors' plans and motives, details of unresolved security issues, and the like. For the record, other areas that we try to keep off this list include: discussions of the group's policies regarding what can be sent to the list, anything remotely ressembling harassment of any person or group of people, and generally anything that doesn't directly relate to technical changes to a WHATWG specification. If you have any questions about this please don't hesitate to e-mail me privately about them (you can even cc www-arch...@w3.org if you want a public record of the conversation). Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] deprecating
On Wed, 2 Sep 2015, henry.st...@bblfish.net wrote: > > > > The spec just reflects implementations. The majority of > > implementations of (by usage) have said they want to drop it, > > There was a lot of pushback on those lists against dropping it, and no > clear arguments have been made for dropping keygen there. That's debatable (see foolip's e-mail), but more to the point, it's irrelevant. We're not trying to reflect consensus here. We're trying to reflect reality. That's why the spec still has , but why it warns that browsers are planning on dropping it. > > and the other major implementation has never supported it. > > You mean IE? IE has always had something that did the same: > > https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx > > It is not idea, and it is easy to use both. I'm not really sure what you're trying to argue here. Are you saying we should specify this API? Are other browsers planning on implementing it? > To replace it with what? That is the problem that needs discussing and > not partially across twenty lists where the issues are only ever half > addressed. Again, the point of the spec here is just to reflect reality; if browser vendors say they want to drop something, then we have to reflect that, even if they don't plan on replacing it with anything. Otherwise, our spec is just rather dry science fiction. Having said that, it's my understanding that there are replacement APIs being developed. I'm not personally familiar with that work so I can't comment on it. Should the authors of a cryptography specification that browser vendors want to implement be interested in publishing their work through the WHATWG, I'm sure that could be arranged, and at that point this list would make for a very relevant place to discuss those technologies. > Indeed: they seem to be working as one would expect where one thinking > that forces that don't like asymetric key cryptography to be widely > deployed were trying to remove that capability as far as possible. The > manner of doing this - by secret evidence, and pointers to closed non > deployed standards - seems to be very much the way of doing of > organisations that like to keep things secret and closed. Asymetric key cryptography forms the basis of the entire Web's security system. It's pretty much the only possible way to have solid security in an environment where you don't trust the carrier. I doubt it's going anywhere anytime soon, unless we suddenly get a supply of securely- sharable one-time-pads... The post foolip pointed to points out that is actually rather insecure (e.g. using MD5). One could argue that _keeping_ is actually more harmful to asymetric-key cryptography than removing it... > The case has been made that things should go the other way around: the > problems should be brought up, and then improvements or replacements > found. When those are found and are satisfactory ( as evaluated against > a wider set of values that take the whole web security into account ) > then one moves forward. I certainly encourage people to follow such a pattern, but when they don't, we can't just ignore reality. I encourage you to read our FAQ. The WHATWG has a much more pragmatic approach than other standards organisations you may be more familiar with. https://whatwg.org/faq -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] deprecating
On Thu, 3 Sep 2015, Melvin Carvalho wrote:
> >
> > The post foolip pointed to points out that is actually rather
> > insecure (e.g. using MD5). One could argue that _keeping_ is
> > actually more harmful to asymetric-key cryptography than removing
> > it...
>
> Im not an expert here, but my understanding from reading some wikipedia
> articles was that a preimage attack on md5 was 2^123. If so, isnt that
> pretty secure? I asked on the blink thread why md5 was thought to be
> insecure, but no one was able to answer, or point to a reference. It
> would be great to understand if there is a feasible attack here.
Wikipedia's article on MD5 is pretty comprehensive:
https://en.wikipedia.org/wiki/MD5
> Looking at:
>
> SignedPublicKeyAndChallenge ::= SEQUENCE {
> publicKeyAndChallenge PublicKeyAndChallenge
> <http://www.w3.org/html/wg/drafts/html/master/semantics.html#publickeyandchallenge>,
> signatureAlgorithm AlgorithmIdentifier,
> signature BIT STRING
> }
>
>
> http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-keygen-element
That's the W3C's fork of the specification. The relevant spec for this
mailing list is:
https://html.spec.whatwg.org/multipage/#the-keygen-element
I wouldn't use the W3C's fork for discussions here because the W3C version
has many subtle differences and it can cause us great confusion when
discussing these issues.
> There appears to be a field signatureAlgorithm. Does that not suggest
> that switching away from MD5 is future proofed?
In principle itself could have new signature algorithms added.
This of course wouldn't be backwards compatible (in that it wouldn't be
supported by legacy UAs or legacy servers), so it would be no different
than introducing an entirely new feature that didn't suffer from all the
other problems that suffers from.
This is somewhat academic, though. When there are no browser vendors
supporting a particular feature, arguing about how it could be improved
misses the point. That's why we added a warning to the spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] deprecating
On Thu, 3 Sep 2015, henry.st...@bblfish.net wrote: > >>> > >>> and the other major implementation has never supported []. > >> > >> You mean IE? IE has always had something that did the same: > >> > >> https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx > >> > >> It is not idea, and it is easy to use both. > > > > I'm not really sure what you're trying to argue here. Are you saying > > we should specify this API? Are other browsers planning on > > implementing it? > > What I am saying is that all desktop browsers have implemented that > functionality in one way or another for 15 years. So that it is > misleaading to make it look like it is only a minority that has been > using it. If you consider and IE's Certificate Enrollment API to be equivalent, then I wouldn't worry about the deprecation warning regarding . I would fully expect a similar feature to be supported by the -supporting browsers long before itself is removed. One might even hope that such a feature would be one developed in a standards environment with input from security expects and with with input from all vendors, and that it might therefore be more secure than and actually implemented by all vendors, which would certainly be an improvement over the current situation. > yes, what is needed therefore is a place where discussions making > explicit the reasons for this ( and other ) decision can be made, so > that the larger community of users of the technologies the browser > vendors are implementing can have a voice, and also like in any open > source project to have a lot of different eyes help work through the > tangle of complexity in this field. If you have specific proposals for changes to the WHATWG specifications, then this mailing list would absolutely be a fine place for that. > > Having said that, it's my understanding that there are replacement > > APIs being developed. I'm not personally familiar with that work so I > > can't comment on it. Should the authors of a cryptography > > specification that browser vendors want to implement be interested in > > publishing their work through the WHATWG, I'm sure that could be > > arranged, and at that point this list would make for a very relevant > > place to discuss those technologies. > > What would be discussed here? As I see your point is that the WHATWG > only publishes what has been implemented already. I encourage you to read our FAQ, which covers such matters in detail: https://whatwg.org/faq Does that answer your question? > yes, but it is not because the JS crypto API has methods to do > asymmetric key cryptography, that it is useable in the way needed for > authentication etc... The problem is that the JS crypto API have not > developed a way to store the prive key in the browser without the JS > from the same origin getting access to it. That is what is missing is a > certain category of security guarantees, which involve User Interface > elements. I encourage you to bring such concerns up with the group(s) developing those APIs. As far as I'm aware, none of the WHATWG specs include JS crypto APIs. (And given that there are already groups working on such technologies, we wouldn't want to start a new spec for those technologies unless the browser vendors indicated that they weren't interested in the existing specs and wanted a new one.) > From the discussions on the blink list it was clear that Ryan Sleevi > thinks that it is a good enough answer for the security of private keys > that they be place in HTML5 web storage. A lot of the decision to remove > keygen and other features depend on mistaken - or if I give him the > benefit of the doubt, at best undocumented assumptions - of this sort. I recommend bringing this up with Ryan. The only change that has been made to the WHATWG HTML spec is adding a note to the effect that the feature is likely to be removed. This is just a statement of fact, reflecting intents stated by browser vendors. It's not a value judgement and it's not a technical or normative change. If you would like to discuss a technical change to the WHATWG HTML spec, then that would definitely be something that this list would be appricate for. To argue against the change that _has_ been made, though, you'd have to show that it wasn't accurate, which would presumably first mean convincing the browser vendors not to deprecate the feature in question. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] deprecating
On Tue, 1 Sep 2015, henry.st...@bblfish.net wrote: > > As the WhatWG only recenly moved to Github members here may not have > noticed that has been deprecated. > > I opened https://github.com/whatwg/html/issues/67 to give space for the > discussion. It is a pitty that this was closed so quickly ( within an > hour ) without giving members and the public ( the users of the web ) > time to comment nor for their voice to be heard. > > This is a complex issue that involves many different levels of > expertise, and it should not be handled so lightly. The spec just reflects implementations. The majority of implementations of (by usage) have said they want to drop it, and the other major implementation has never supported it. The element was originally (and for many years) purely a mostly-undocumented proprietary extension; at the time it was invented, the HTML spec was edited by the W3C and the W3C did not add it (they only ended up speccing it in their most recent HTML spec because they forked the WHATWG's spec which did define it -- indeed, even then, it was something that W3C HTML working group members argued should not have been included). It was only added to the WHATWG spec because one of the browser vendors said they could not remove support for it due to usage by enterprise customers; that browser vendor is now amongst one of the ones wanting to drop it. As far as I can tell, therefore, things here are working exactly as one should expect. It's worth noting that is a pretty terrible API. I recommend approaching the groups writing new cryptography APIs, explaining your use cases, and making sure they are supported in up-and-coming, more widely supported, more secure, and more well-thought-out APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTML spec now on GitHub
Just a heads-up to those of you who like to follow the nitty gritty of spec development here: The HTML spec has joined the other WHATWG specs on GitHub, rather than being alone in the svn.whatwg.org SVN repository. This will enable other WHATWG editors to also contribute to the HTML spec, so you might get replies from Anne, Domenic, or Philip rather than just me. As part of this we are also going to move to using GitHub issues rather than bugs in the W3C Bugzilla. (This also means the widget in the lower left is gone for now. Hopefully we'll figure out a way to add that back.) Don't worry though, we're still going to track the bugs in the W3C Bugzilla, there's no need to manually go and move them over or anything. Let me know if you have any questions. In theory this shouldn't really have any practical impact on anyone except us editors and those of you filing bugs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] EventSource and data URLs
On Mon, 27 Apr 2015, Anne van Kesteren wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? It's definitely intentional that EventSource not introduce any new exceptions to the networking layer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script parsing mode within SVG sections in HTML documents
On Sun, 21 Jun 2015, Niels Keurentjes wrote: I ran into a discussion on Stack Overflow in this topic: http://stackoverflow.com/q/30952737/1729885, regarding embedding the following code snippet in an HTML document: svgscript#x61;#x6c;#x65;#x72;#x74;#x28;#x31;#x29;/script/svg The character references translate to alert(1). I have confirmed that, in all the latest versions of IE, Chrome and Firefox, this code is executed, whilst it is not if the svg container is omitted. I neither think this is intentional nor wanted behavior, as HTML5 explicitly defines a separate script parsing mode which handles character references as plain text. It's not great, but it is intentional. Within svg and math blocks, we use the foreign content parsing mode wherein parsing is much more similar to legacy XML parsing than legacy HTML parsing: https://html.spec.whatwg.org/#parsing-main-inforeign Note in particular that the special behaviour for script here doesn't include changing the tokeniser mode, like it would in non-foreign content. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] MetaExtension and Dublin Core revision
On Sat, 11 Apr 2015, Andrea Rendine wrote: I hope you judge WebDevData a reliable source. Seems reasonable to me. Can the table be fixed accordingly? As I said in my last e-mail, my recommendation is to make whatever edits you think are necessary within the following constraints: - any values that are used in the wild should be included - values that are used in the wild in a consistent manner should be specified in the relevant specification (this might require changes to that specification) - values that are widly used inconsistently should be obsoleted by the relevant specification and marked accordingly on the relevant wiki - the concept of namespaces for these values should be excised from any specification that attempts to introduce it - the description in the wiki should be brief, should deep-link to the relevant specification, and should include brief parentheticals for any usage notes, linked to the relevant specification for more discussion -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Sun, 12 Apr 2015, Anne van Kesteren wrote: On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote: I'd strongly recommend against adding new methods. It'll mean we now have two different ways to do the same thing, which means more bugs, which means less interoperability, more confusing behaviour for authors, more to document, etc. If the existing method didn't have the flaw with the title argument I wouldn't have suggested it. Also, since they both built upon the same primitive I think we'd be okay in the bugs and interop department. You are more optimistic than I. In any case, I strongly recommend against such redundancy. On Wed, 15 Apr 2015, Majid Valipour wrote: Actually URL is optional in current spec and it defaults to current URL. Why is this suboptimal? Because it means you can't bookmark the state or share the state, reloading the page loses the state, etc. In anycase If making URL required is a goal then it is best done by introducing a new method to avoid breaking compatibility. Why is that better? I personally find a dictionary with only optional members which have appropriate defaults to be very convenient. I don't disagree... for new APIs. But when we already have an existing API, maintaining consistency and lack of redundancy IMHO trumps pretty much everything else, if you want the end result to be usable. A lot of the pain with using the Web's APIs is the inconsistency and redundancy that is rampant throughout. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Thu, 19 Mar 2015, Majid Valipour wrote:
Almost all browsers restore scroll position when a user traverses
history. This behavior works well for document style web sites but it is
often not appropriate for single-page web applications where the page
content may be reconstructed (often asynchronously) upon navigation and
where the application wants to control the details of visual transition
between UI states.
Seems reasonable.
Avoid document scrolling altogether by fixing body size and putting
content in an inner scrollable div. This breaks browser features that
depend on document scrolling such as top controls hiding, or overscroll
visuals and in some cases disables fast scroll optimizations for
document scrolling.
Also really it's a bug in browsers that such divs aren't getting the
scroll position restored as well.
Below is the IDL for the proposed changes:
partial interface History {
void pushState(in any data, in DOMString title, in optional DOMString
url, in optional StateOptions options);
void replaceState(in any data, in DOMString title, in optional DOMString
url, in optional StateOptions options);
readonly attribute StateOptions options;
};
dictionary StateOptions {
Boolean restoreScroll = true,
}
I'm not sure there's much point exposing history.options, what's the
purpose of that?
Also, I'd recommend an option name that suggests more strongly that the
author is expected to restore the position themselves, rather than just
that the position shouldn't be restored. For example, calling it something
like willRestoreScrollPosition (defaulting to false, meaning the UA
should do it).
On Wed, 25 Mar 2015, Anne van Kesteren wrote:
The only suggestion I have is that instead of having four-argument
methods we might want to consider introducing two new methods that take
a dictionary. E.g. history.push() and history.replace(). Giving the page
more control over the scroll position when navigating makes sense to me.
I'd strongly recommend against adding new methods. It'll mean we now have
two different ways to do the same thing, which means more bugs, which
means less interoperability, more confusing behaviour for authors, more to
document, etc.
I think the original approach of adding a fourth argument is much better.
It's also a better API in general, since the URL should always be given.
If we had a one-argument form with a dictionary, people would consider not
giving the URL but just disabling scrolling, which is suboptimal.
On Wed, 25 Mar 2015, Jonas Sicking wrote:
Is this really something we should tie to the pushState/replaceState
API?
It seems like websites that lazily add more content as the user scroll
down, like the facebook feed or twitter feed, might not use
pushState/replaceState, but would still like to handle restoring scroll
position themselves.
On Thu, 26 Mar 2015, Simon Pieters wrote:
Yeah... also consider navigating back and forth between two different
sites/apps, without navigating within each site/app. Should they be able
to turn off scroll restore?
Is this something that should be toggled on a per-page basis or on a
per-navigation basis? If per-page, is it enough to just be able to turn
it off (i.e. not turn it on again)?
These are interesting points.
It seems like what you really want is a way to hook into the scroll
behaviour. For example, we could fire an event at the document saying
we're about to automatically scroll to 75% of the way down the page,
cancel this if you want to do it yourself. The real problem with that,
though, is that 75% means nothing in the cases where you'd want to
actually do it yourself. It's not clear to me how you could convey the
information that is actually needed.
Maybe infinite-scroll pages _should_ use replaceState(), to say how much
they have loaded. At which point, the boolean flag seems reasonable again.
Are there other vendors interested in implementing this?
If not, I recommend that Chrome implement this as the fourth argument with
a dictionary with a boolean that implies that the author will perform the
scroll position restoration behaviour themselves, and then filing a bug on
the spec with the Target Milestone set to Needs Impl Interest.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] MetaExtension and Dublin Core revision
On Thu, 26 Mar 2015, Andrea Rendine wrote: - The properties dc., ... are to be REMOVED Are they used by people? If so, it seems like it's the DC specification that should be fixed. It isn't the fact whether they are used or not. Whether they're being used or not is pretty much the most important criteria for whether it should be included in the registry wiki page. They are associated with link rel=schema.dc href=http://purl.org/dc/elements/1.1/;, which is similar to a namespace declaration. Those values aren't defined in that namespace, nobody used them at the beginning because they weren't defined. I'm not sure what this means. There's no namespace declaration concept for link rel or meta name. The names are opaque and each individually defined. I'm not sure what you're saying here. Isn't the DC spec a more appropriate place for such warnings, though? The fact is, the first 15 DC.prefixed properties are older and listed in a sort of legacy compatibility. It's probable that some authors have used them in the past, when they were defined (without a proper range, es Agent, Date, Resource, Literal, etc.), so they've been listed in the table as well. But now a more modern and up-to-date namespace exists, defined by the link rel=schema.dcterms href=http://purl.org/dc/terms/; namespace declaration. Newer authors who start using Dublin Core metadata should use this declaration, at least if they're going to use properties in their defined range. See http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces I don't see why this is relevant for the meta wiki. It should just list all the terms that people use or could use, linked to the relevant spec, with a brief description. That description can say (deprecated, see spec) or (commonly misused, see spec) or some such, where that text is a link to a discussion of the state of the art in the spec, of course. dcterms.collection Is it used by anyone? It has no meaning for documents. It defines a datatype. If it is used, it is used incorrectly. If it's used incorrectly 100% of the time that it is used, then the problem is probably with the spec, not with the use. The properties dcterms. are to be REMOVED Again, are they used by anyone? Again, the spec says they mustn't, as they're meant to define a link@rel element rather than a meta@name. They'd make no sense when used with a string, they refer to a URI. Ok, but that doesn't answer the question. If they're used, we shouldn't remove them, we should fix the underlying spec to say how to handle the existing content that uses them. On Thu, 26 Mar 2015, Andrea Rendine wrote: According to the spec, the properties marked in my mail can be used as DC-prefixed, though in the wild the DCTERMS prefix is largely preferred. If these properties were to be used, it should be specified that the correct namespace declaration is *not* link rel=schema.dc href= http://purl.org/dc/elements/1.1/;, but something like link rel=schema.dc href=http://purl.org/dc/terms/;. DC prefix is used with both namespaces for legacy compatibility, but the prevalence of DCTERMS over DC is about 100 to 1. There's no concept of namespaces here. If the DC spec says there is, it should be fixed. On Thu, 2 Apr 2015, Andrea Rendine wrote: Mr. Hickson, please let me know if further details are needed, or otherwise if change proposal will be accepted, at least partially. The more those properties remain there, the more authors can read them and use them incorrectly IMHO. My recommendation is to make whatever edits you think are necessary within the following constraints: - any values that are used in the wild should be included - values that are used in the wild in a consistent manner should be specified in the relevant specification (this might require changes to that specification) - values that are widly used inconsistently should be obsoleted by the relevant specification and marked accordingly on the relevant wiki - the concept of namespaces for these values should be excised from any specification that attempts to introduce it - the description in the wiki should be brief, should deep-link to the relevant specification, and should include brief parentheticals for any usage notes, linked to the relevant specification for more discussion -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] MetaExtension and Dublin Core revision
On Tue, 17 Mar 2015, Andrea Rendine wrote: Changes to make: - The properties dc.created, dc.date.issued, dc.dateCopyrighted, dc.dateSubmitted, dc.license, dc.mediator, dc.medium, dc.modified, dc.provenance, dc.references, dc.temporal, dc.valid are to be REMOVED because not defined by the specification. Are they used by people? If so, it seems like it's the DC specification that should be fixed. + The properties [...] are to be INTRODUCED [...] That should be non-controversial. + all dc.prefixed properties should present a note advising authors NOT to use them when a value in the proper range is to be provided (/elements/1.1/ namespace is maintained for legacy reasons, as some properties could have a value not fitting the range as it was defined in 2008 revision; however, now specific ranges have been defined, so it is auspicable that authors conform to them; in that case the more specific /terms/ namespace properties: http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces). I'm not sure what you're saying here. Isn't the DC spec a more appropriate place for such warnings, though? - The property dcterms.collection is to be REMOVED as it defines a class of properties in DCMI specification, not a real property Is it used by anyone? - The properties dcterms.hasFormat, dcterms.hasPart, dcterms.hasVersion, dcterms.isFormatOf, dcterms.isPartOf, dcterms.isReferencedBy, dcterms.isReplacedBy, dcterms.isRequiredBy, dcterms.isVersionOf, dcterms.references, dcterms.relation, dcterms.replaces, dcterms.requires, dcterms.source, dcterms.subject are to be REMOVED, because per spec these properties are meant to define non-literal values and as such meta@name is not suitable. Again, are they used by anyone? + Properties whose value can reasonably be either a literal or a non-literal surrogate should be marked with a note stating that, if a resource non-literal reference is to be provided, it is better to use a link rel=dcterms.property href=reference title=literal definition / rather a meta element whose content is a string. I don't really understand this either, but it seems also like something that should be done in the relevant spec, not the registry. + Prefix structures, both in namespace definition link rel=schema.DCTERMS/DC and in properties meta name=DCTERMS/DC should be capitalised both in existing properties and in those defined in this message (I wrote them lowercase for the sake of uniformity). Aren't these values case-insensitive? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Obsolete Feature [hgroup]
On Tue, 17 Feb 2015, Barry Smith wrote: I have read where the W3C has made the hgroup element obsolete, http://www.w3.org/html/wg/drafts/html/master/obsolete.html#non-conforming-features . I see the specification is still in the WHATWG HTML: The Living Standard specifications. Are there any plans to remove this element from the specification? Not currently. If not, as a web developer, I try extremely hard to follow protocol and create a valid and semantically correct document. How should I handle this? If you wish to create a valid and semantically correct document according to the most recently published HTML standard, then using hgroup is fine. As far as validation, a document with the hgroup element will not pass when using the W3C Markup Validation Service. However it will pass when using the https://html5.validator.nu/ validator. Should I ignore the error I receive? I recommend using the validator.nu service rather than the W3C one. They're basically the same but the validator.nu one is closer to the WHATWG spec's requirements than the W3C one. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] BroadcastChannel in Firefox Nightly
On Wed, 14 Jan 2015, Janusz Majnert wrote: On 14.01.2015 14:01, Anne van Kesteren wrote: Andrea just landed the last patch for the BroadcastChannel API: https://bugzilla.mozilla.org/show_bug.cgi?id=966439 https://html.spec.whatwg.org/multipage/comms.html#broadcasting-to-other-browsing-contexts Assuming everything sticks it'll start appearing in Firefox Nightly soon. We thought we'd give everyone a heads up we're doing this since it hasn't been discussed much. From quickly skimming the linked spec it looks like the same functionality (minus sending objects) is already available with the use of WebStorage: https://html.spec.whatwg.org/multipage/webstorage.html#the-storage-event If you look at the bug that introduced this feature, you'll see that avoiding abusing localStorage was in fact the original motivation for this API. :-) https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
specific styling effects * the :has() pseudo class is not part of the so called fast profile, which means that by spec, CSS implementations must not support it (the DOM query() method should). On Thu, 27 Nov 2014, Florian Rivoal wrote: As selectors is a CSS topic as much as an HTML one, I brought this to the CSS working group (mailing list then telecon) for further discussion to see if its members thought this was worth pursuing or not before coming back here. The group made a resolution agreeing that :hover and :active should be made to propagate bidirectionally between labels and labeled controls, as the behaviour was found useful, and the performance question not problematic. Given that two vendors here said the performance question was problematic, I question that judgement. Since you raised specific concerns about performance, Microsoft, who already implements this, went through their bug database to check: “there is not a single bug filed against IE regarding performance issues by tying the the label to the labeled control”. Different vendors have different thresholds for performance concerns. I haven't added this, since two vendors here raised some concerns and there doesn't seem to be a strong use case or much demand. It can be somewhat trivially worked around using some script or by constraining the markup appropriately. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menuitem: Issue reported by the web developers
On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have menuitem, menu and hr generate implied /menuitem end tags. (Maybe other tags like li and p can also imply /menuitem.) The label attribute be honored if specified, otherwise use the textContent with leading and trailing whitespace trimmed. This would allow either syntax unless I'm missing something. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menuitem: Issue reported by the web developers
On Wed, 26 Nov 2014, Sanjoy Pal wrote: As per specification [1][2], menuitem should not have end tag, but few websites uses menuitemSome markup/menuitem which resulted in broken sites[3][4]. Firefox allows menuitemSome markup/menuitem. So, we are wondering if specification can be modified to allow menuitemSome markup/menuitem for backward compatibility. Do we know how many sites are affected? As I see it there's basically three choices -- in my order of preference, they would be: - break the sites: if there aren't many, and especially if they can be evangelised to avoid these mistakes, then we should just do that - rename menuitem to something else, like command: this would be unfortunate, since the feedback from Mozilla a few years ago was that they'd rather have menuitem than command, and it would also mean some parser churn, which is always bad, but it would probably be reasonably safe to do if we can find a good replacement element name - change menuitem's semantics so that the label comes from the element's textContents instead of a label= attribute (and charge the parser accordingly): not sure how compatible this would be; it has numerous disadvantages, too, like making people think they can put markup in the element (look at the Apple page for an example), which wouldn't work There may be other options that aren't immediately coming to mind. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] URL interop status and reference implementation demos
On Tue, 18 Nov 2014, Sam Ruby wrote: Anne has kindly given me access to the directory on the server where the url.spec lives. I've started to move some of my work there. https://url.spec.whatwg.org/interop/urltest-results/ IMHO it's probably best to keep data like that on personal sites (or on the wiki) rather than on the spec's site. If it's on the spec's site and it starts getting out of date with no-one maintaining it, we'd want to 410 it to reduce confusion, but then the data would be lost, which would be unfortunate. (That's why, for example, I put all my tests and demos on hixie.ch or damowmow.com, rather than on html.spec.whatwg.org.) You could use the wiki; that's essentially defined as the sandbox for the WHATWG, where stuff can easily get stale but isn't supposed to be treated as in any way authoritative (the FAQ notwithstanding). I also have a reference implementation I've been working on. By reference implementation do you mean a normative one? If it's just a regular implementation, then it should definitely not be on the WHATWG site, IMHO, since that would mislead other implementors into thinking it's special. If it's actually intended to be a true reference implementation, then that's interesting; is this intended to replace the spec in due course? Generally I would recommend only putting specs on *.spec.whatwg.org. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modifying the URL inside beforeunload event
On Thu, 13 Nov 2014, cowwoc wrote: In any case, the question seems to be whether history.replaceState() should be honored in beforeunload. Individually, each one is very well defined, but I don't see any discussion of what should happen when the two are used together. You just follow their algorithms. I don't understand what needs to be additionally specified. Can you elaborate? The beforeunload algorithm is here: https://html.spec.whatwg.org/#prompt-to-unload-a-document You get to step 4, then run script, which calls replaceState's algorithm: https://html.spec.whatwg.org/#dom-history-replacestate The session history entry gets updated. Then you return to beforeunload, starting at step 5. Eventually 'salvageable' gets set to false, and much later (when running the 'unload' algorithm) the doc gets discarded, without affecting the (mutated) session history entry. Are you saying that history.replaceState() should succeed or fail in this case? It should do what is specified. I'm not sure what succeed or fail would mean in this context. If you don't want the tabId to be shared, you shouldn't put it in the location bar in the first place -- removing it from the history is too late, because people copy and paste URLs from the location bar while the page is up. You could replaceState() during page load, but I would generally much more recommend sessionStorage for this purpose. Using sessionStorage alone wouldn't work because the goal of this exercise is to send the server a different authentication token per browser tab. I can store these tokens in the sessionStorage (in fact, I do) but that's not enough because the browser still needs to send the token to the server with each request. I hope this clarifies my dilemma. http://stackoverflow.com/a/26901232/14731 explains how my current implementation works. It's very lengthy and ugly so I'm more than happy to entertain alternatives. Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modifying the URL inside beforeunload event
On Fri, 14 Nov 2014, cowwoc wrote: 1. Say we have two pages: OLD and NEW. 2. OLD contains a link to NEW. 3. I start off on OLD and click on the link. 4. The above logic runs (beforeunload event handler changes the URL using history.replaceState() from OLD to CHANGED) 5. The browser navigates to the NEW page. 6. Now... when the user examines the URL associated with the back-button, should he see OLD or CHANGED? Unless I'm missing something, I'm pretty sure it should be CHANGED. I see no reason why it would make a difference whether the replaceState() call happens before or during the beforeunload handler; in either case, the history traversal hasn't happened yet. Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. You mean you have a single-paged application and rewrite the underlying page asynchronously? More or less. Google Calendar is an example of the kind of app I mean (though obviously that's not one I've written myself!). How do you deal with needing to load different Javascript files per page? You either load it all asynchronously, or you load it on-demand. Depends on your precise setup. Generally speaking I find that most of the logic ends up on the server; there's just not that much to do purely on the client side. Obviously that depends on how sophisticated the app is. If it's a game with crazy visuals, there's comparatively more client-side code. Similarly, if you have a rich-text editor with offline capabilities, there's obviously much more client-side code. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modifying the URL inside beforeunload event
(pushing this to the top of the queue by request) On Sun, 2 Nov 2014, cowwoc wrote: I would like to bringhttps://code.google.com/p/chromium/issues/detail?id=428583 to your attention. Quoting comment #9: I believe this is a corner case that is not adequately described. I was imagining adding a clause somewhere around step 8 inhttps://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:beforeunloadevent http://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:beforeunloadevent. Specifically, clarifying what the behavior should be if an event handler modifies the url. I believe I have a legitimate use-case (described in comment #9) for needing to change the URL in beforeunload. I am open to alternatives that allow me to achieve the same end-result, but I have not found any good solutions to date. I don't really understand what's unclear here. Can you elaborate? As far as I can tell this is one of the better defined interactions, since the unload algorithm and the pushState algorithm are pretty specific. Generally speaking, though, for your use case you should just use sessionStorage rather than cookies. That's what sessionStorage is for. If you don't want the tabId to be shared, you shouldn't put it in the location bar in the first place -- removing it from the history is too late, because people copy and paste URLs from the location bar while the page is up. You could replaceState() during page load, but I would generally much more recommend sessionStorage for this purpose. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] script content restrictions vis-a-vis HTML template data blocks
On Wed, 5 Nov 2014, Jesse McCarthy wrote: Re: the Restrictions for contents of script elements (4.12.1.2): Consider script elements containing data blocks. It's useful to embed templates in these; HTML templates for example. When embedding HTML templates, it would be onerous to have to either omit comments or implement an escaping / unescaping regimen. Have you considered using the template element? The following examples illustrate my interpretation of the requirements for script content. Is this correct? Non-conforming (does not match the outer production before comment-open / after comment-close / or both): script type=text/plain!-- a --/script script type=text/plain !-- a --/script script type=text/plain!-- a -- /script These are all conforming; don't forget that the empty string is a string so outer matches the empty string. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New feature: better integration with browser find interface
On Wed, 29 Oct 2014, Peter Kasting wrote: On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson i...@hixie.ch wrote: - telling UA that it should retry the search because content has been changed/rendered/modified The last is important because for web application which dynamically render the content, after search has already find matches on the page, if content is changed, browsers do not retry the search. This is the most evident with browsers which allow highlight all feature, like Google Chrome. This is just a bug in the browsers. If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. How large? On Thu, 30 Oct 2014, Robert O'Callahan wrote: It seems possible to me: 1) You can do it lazily, during idle time (though some apps don't have any) 2) You can do it incrementally 3) You can start with the visible part of the page You can also use a rate-limitting and back-off strategy -- only update find every second or so at most, and if the user hasn't interacted with the page, do it even less often. There's no reason to do it every nanosecond as the page is modified. Having said that, it would be complex enough I don't know if it would ever be worth implementing. In its most basic implementation, where you only do it every few seconds and only if the user has interacted with the page recently, it seems relatively simple, especially if you don't bother with the incremental aspects. As someone who deals in large pages and searches in those pages a lot, I find the lack of dynamic find-in-page to be a regular nuissance, FWIW. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Shared storage
On Sat, 15 Feb 2014, Brett Zamir wrote: The desktop PC thankfully evolved into allowing third-party software which could create and edit files shareable by other third-party software which would have the same rights to do the same. The importance of this can hardly be overestimated. Yet today, on the web, there appears to be no standard way to create content in such an agnostic manner whereby users have full, built-in, locally-controlled portability of their data. Why can't you just do the same as used to be done? Download the resource locally (save, using a href download), then upload it to the new site (open, using input type=file)? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New feature: better integration with browser find interface
On Sun, 23 Feb 2014, Mitar wrote: If you open a long document in Google Docs not whole document is rendered immediately so DOM does not contain whole document. If [...] you invoke find through browser menu you get browser's original find interface which does not really work and does not find anything on page not yet rendered. [...] Mozilla pdf.js HTML5 PDF library [...] Rendering whole PDF would consume too much resources so only pages visible to the user are added to DOM. Browser thus cannot find content on pages not visible. [...] Have same workaround of intercepting a ctrl-f keystroke. [...other similar use cases...] - styling of how matched text looks, and how highlighted text looks (when user selects to highlight all matches in UAs that support that) - some browsers reuse selection style (Firefox), some browsers have special style you cannot style with CSS (Chrome) The various use cases you gave didn't seem to be derived from this need. How much of a need is this? - telling to the web application that search is being in progress and what is being searched for That does seem to be something that is necessary. I've filed a bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27186 - telling UA that it should retry the search because content has been changed/rendered/modified The last is important because for web application which dynamically render the content, after search has already find matches on the page, if content is changed, browsers do not retry the search. This is the most evident with browsers which allow highlight all feature, like Google Chrome. This is just a bug in the browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Markup-related feedback
On Fri, 24 Jan 2014, Jukka K. Korpela wrote:
2014-01-22 2:28, Ian Hickson wrote:
On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
Thank you for the clarifications. I may have been stuck to an idea
of a submittable element, possibly adopted from some earlier version
or proposal. I think an explicit short note like The output element
is not submittable would be useful.
I am reluctant to add that kind of comment for a couple of reasons.
First, there's the problem of determining when one would add these
notes. Should the spec be explicit about everything it doesn't say?
No, but it should be explicit about things that could easily be
misunderstood.
Fair enough. I've added some text to this effect.
What I would rather do is clarify whatever led to the confusion in the
first place. Do you have any idea what it is in the output section
that might lead you to think that it would be submittable?
Well, it is under the heading 4.10 Forms. As an element for the result
of some scripted operation (which output seems to be meant for),
output need not have anything to do with forms. But when it is under
Forms, a natural idea is oh, this is for some computed value, like a
total, to be submitted.
In the sentence I added, I added a mention of why there's a relationship
to forms.
(A submittable output element would a natural thing to have in many
cases, e.g. in showing some calculated total to the user and
submitting it along with form data, for checking purposes.)
Can you elaborate on this use case? I'm not sure how it would work.
When you calculate the total with JavaScript, mainly to be shown to the
user, you might as well submit it along with the form, as an extra
check. If it does not match the total calculated in the server,
something went very wrong. What you do then is a different question, but
the important thing is that you detect a problem, instead of charging an
amount that differs from what the user saw.
Fair enough. You can do this with type=hidden, for what it's worth.
The main reason for not submitting it so far has been that it would
risk authors relying on the client's computation and thus not doing it
on the server,
Authors often rely too much on checks and computations made client-side
- including new features like @pattern and @required attributes and new
values of the @type attribute. They have always been able to do that
with calculated totals, for example - just using an input element
(possibly with @readonly).
Right. But this makes it easier.
Without name=, the main purpose of output -- making it easy to
update non-form-control values in script -- is lost.
The @name attribute in general, except for submittable controls, is
legacy markup that has caused much confusion. It was introduced long
ago, before @id was added to HTML, for scripting purposes, on @img and
@form, as well as on @a for link destinations, but it was unsuitable
from the beginning. It was not defined to be unique in the document, and
there have been many attempts to phase out/deprecate/obsolete @name
(except for submittable fields, where it need not be unique).
So it looks a bit odd to introduce @name for a new element.
What you say is true for some uses of name=, but in the form API in
particular, name= works pretty well, due to the elements object.
Consider what this would look like without the form.elements API:
form name=main
Result: output name=result/output
script
document.forms.main.elements.result.value = 'Hello World';
/script
/form
With output id=result/output, it would have
document.getElementById('result').value = 'Hello World'
and if jQuery is used (and more than half of the world uses it, or
something similar), it would have
$('#result') = 'Hello World'
I would say that both ways are simpler than the property chain
document.forms.main.elements.result.value and, moreover, a way that can
be used to access any element, not just output.
I guess this is an area where opinions differ.
Well, more or less by definition, [if] output is appropriate for
something, it's more appropriate than span would be, since span is
more generic. span is like the fall back element, it has
essentially no semantics at all.
That's a rather theoretical proposition. You say that output is for a
result of a calculation or user agent and call this semantics.
That's basically how that works, yes. :-)
But how would that be a tangible benefit.
The main benefit is the one I describe above, the way it interacts with
the form elements API. The benefit of the semantics is the same as the
benefits of any semantics, mainly that it makes code maintenance easier,
makes it easier for new authors to enter a project and know what's going
on, etc.
I think the improvement of o relative to
document.getElementById('o') should be self
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, 1 Oct 2014, Domenic Denicola wrote: This sort of behavior makes promise rejection essentially worthless. They are as worthless as exceptions. Some exceptions _are_ worthless, as witnessed by the fact that nobody ever tries to catch them. For example, TypeError. This is why I've argued before that these worthless exceptions should continue to be real exceptions even in the Promise case. Incidentally, this bug and this comment in particular are quite relevant to this thread (regarding how to design an API with promises): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472#c18 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Autofill-related feedback
to the former level3, and add a new level5 which is the former level4. Maybe. This could cause quite the mess. I guess we'll handle this in due course on a case-by-case basis. It's hard to see how we could predict all the various ways this might change. In the end (as part of the related bug) I did spec the four level values. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo Vela wrote: On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: What about X-Content-Type-Options: nosniff? Could we formalize it and remove the X and disable sniffing all together? Do you mean for manifests specifically, or more generally? I agree it's wrong to do it as a one-off, so was hoping to make it more generally (since there seems to be a move on moving out of the CT model). I don't think removing sniffing in general is ever going to happen, if for no other reason than for many types it's just trivial to sniff and very unlikely to go wrong (e.g. binary image types). If that's not OK, then CSP is probably a reasonable way forward (I'll take a look at the Service Worker thread to ensure we have a similar mitigation in place). Yeah, CSP seems like the logical way to do this. On Tue, 13 May 2014, Michal Zalewski wrote: I disagree. Much of the Web actually relies on this today, and for the most part it works. For example, when you do: img src=foo ... ...the Content-Type is ignored except for SVG. Well, img is actually a fairly special case of content that is difficult for attackers to spoof and that can't be easily read back across domains without additional CORS headers. But I believe that in Chrome and in Firefox, C-T checks or other mitigations have been recently added at least script, link rel=stylesheet, and object / embed, all of which lead to interesting security problems when they are used to load other types of documents across origins. Similar changes are being made also for a couple of other cases, such as a download. script is news to me. Per spec it has no sniffing or Content-Type checking, it just assumes text/javascript. object/embed, at least if it matches the spec's Content-Type requirements, still involves plenty of sniffing. link rel=stylesheet has required text/css for some time. CSS is a text format with no signature so there's no good way to sniff it. On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: If CSS, JS and plugins had magic numbers at the beginning of the file, then that would prevent the issues that you are discussing right? Some of them. I think that's Ian's point, that for those file types, we need CT, but for others, like manifest files, and image and plugins we shouldn't need. Right. PDFs, and JARs are a special case here, since they scan the content (first N bytes, or last N bytes) for the signature, but if the content match was done for the exact first byte, then this would help prevent security issues I think? Having a loose signature is problematic, indeed. Note that the MIME Sniffing spec, for PDF, doesn't allow scanning. On Tue, 13 May 2014, Michal Zalewski wrote: If we take this route, I think we'd be essentially making sure that many web applications that are safe today will gradually acquire new security bugs out of the blue as the UA magic signature detection logic is extended in the future (as it inevitably will - to account for new plugins, new formats with scripting capabilities or other interesting side effects, etc). An out-of-band signalling mechanism has far superior security properties compares to an in-band one, given how many if not most web apps are designed today. It may be that they are designed the wrong way, but the security rules were never particularly clear, and serving content off-domain added a lot of complexity around topics such as auth, so I think it's best to be forgiving and accommodate that. The examples of CSV exports, text documents, and several more exotic things aside, most JSONP APIs give the attacker broad control over the first few bytes of the response. I agree that out-of-band signalling has some security advantages, but I think they are far outweighed by the costs of configuring out-of-band signalling in practice. Either way, the Web now is in this weird mix of both approaches, and we're unlikely to be able to do anything about that. On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: @Ian, is there a way to find out what was the Content-Type that the authors that complained were getting? Hopefully we can figure out a list of Content-Types that are unlikely to cause security problems? I think the mitigation in the spec (scoping the fallbacks to the manifest URL path) is probably sufficient. It means you can only take over the part of the site that has the upload vulnerability. Supporting just the default types is unlikely to help, since those are the types most likely to be used to label an uploaded file in this scenario. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Move RequestAnimationFrame steps into HTML?
On Wed, 17 Sep 2014, James Robinson wrote: Cameron and I are editors of the Timing control for script-based animations spec, more commonly known as the spec for requestAnimationFrame. This spec has some outstanding feedback from folks like Anne that needs to be addressed at a basic editorial level that I haven't had bandwidth to address. It also needs to integrate more tightly into the HTML's rendering model to get proper timing. I think that adding the appropriate hooks to both specs will be complicated and I know I don't have the bandwidth to do this correctly, so I propose that we simply move this algorithm into HTML itself and ask that the HTML editors (aka Hixie) take over this part of the spec. I'd be happy to do this. I've filed a bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26839 This will actually help substantially with resolving this issue also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26636 Do you have a log of the issues that are outstanding on this spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Preloading and deferred loading of scripts and other resources
.
HTTP caching semantics would be honoured (or not) as they are now.
On Tue, 26 Aug 2014, Ilya Grigorik wrote:
The first thing that strikes me about this entire topic is its scope,
and I'm wondering if we should take a step back and (a) extract some
lower level primitives, (b) leave the rest to libraries and web
developers to experiment with, and (c) if (b) leads to some good
patterns, then codify them at a later date... Instead of trying to
tackle all of this at once.
That's exactly what I tried to do here.
In particular, it seems like we might be coupling two topics:
(1) a flexible declarative mechanism to fetch arbitrary resources
(2) some set of mechanisms to express dependencies, execution order, etc.
If we do our job right with (1), I think (2) can (should?) be deferred
to developers and library writers.
(1) is what we did in the past, and now we're doing (2) given the
experience that we've gotten over the years.
Specifically, for (1):
- We need a way to initiate arbitrary downloads that doc + preload
parsers will understand and can process
- We need a way to communicate type, prioritization, MQ, and other custom
fetch information for each download
- We need a way to listen on download progress of these resources to build
custom processing logic
- By default there is no UA processing on the response, this mechanism
simply fetches bytes
Isn't this just XHR?
I really like your proposal for as=... Concretely it could look something
like this:
link rel=preload
href=/some/asset.css
as=stylesheet(used to initialize default priority, headers,
etc)
load-settings={} (JSON payload with custom headers, priority
[2], etc)
media= ... (relevant media queries..)
probability=([0.0-1.0] used for speculative fetches [3])
I don't understand why this would be better than:
link rel=stylesheet loadpolicy=declare href=/some/asset.ass
loadsettings=... media=...
The combination of all of the above allows me to fetch any content-type,
specify custom priorities and headers (or use a default set via 'as'),
apply MQ's, etc. Given all that, assuming I can extract a Promise/Fetch
object (or some such) out of it, I can then track the download progress
and apply any arbitrary logic for how and when it should be processed.
You can do all this with the proposed markup, except that the proposed
markup avoids having to categories all resource load types, and the fetch
for a particular type is kept associated with its core element (e.g.
script loads are still associated with script), so that you can
trivially apply the resource (remove declare) when needed.
For example:
- I can execute a script immediately by waiting for the download to finish
and inject the script tag referencing same URL
Why is this better than just telling the browser to run the script and
letting it manage the load?
- I can setup a callback that waits for any other arbitrary resource to
finish before I execute it...
- I can defer execution until a particular action occurs.
The proposal I put forward lets you do these too.
- I can prefetch arbitrary resources for later use
Sure. You can do this today.
(note: the script example is completely arbitrary.. the entire point is
that this mechanism is independent of content-type)
It's not actually independent, since you have to give the as attribute
to tell the user agent how to preparse it, and then when you do execute it
you still have to know how to invoke it (and we have to hope the browser
associates the two loads together rather than starting a new one).
In other words, it seems like you could build most (all?) of the doc'ed
use cases in client-land... I can implement needs, loadPolicty,
addDependency on my own. Which, in my books, is a much better outcome
anyway because it will allow more and much more rapid experimentation.
You can do all those today. The whole point here is to take the most
common things that people do, and build it into the browsers so that you
don't have to write script and so that the browsers can do a better job.
On Mon, 25 Aug 2014, Simon Pieters wrote:
On Sat, 23 Aug 2014 02:44:23 +0200, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Mar 2014, Boris Zbarsky wrote:
I realize no one would write actual code like this; the real-life
use case I'm worried about would be more like this:
// img is already loaded sometimes
// Would like to observe a new load
var promise1 = img.loaded(); // oops! This will be pre-resolved if
// we were already loaded, but otherwise
// will resolve with the new load we're
// about to start.
img.src = bar;
promise1 would be rejected as soon as you set 'src' if it hadn't
loaded yet.
The old image doesn't stop loading immediately when setting
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Mon, 8 Sep 2014, Ilya Grigorik wrote: Better or worse is not the point. I think the current proposal fails to address the larger underlying problem. If it did, then that would be worse. The platform is missing a lower-level primitive (declarative and imperative) that is able to explain resource loading with the same expressive power as requests initiated by the browser itself. That isn't a problem. XHR provides arbitrary resource loading, but it lacks the power to express transport-layer options such as relative request priority That is fixed by exposing Request initialisation flags on XHR. and dependencies, That's fixed by using the proposal in this thread. and it also hides requests from the preload scanner, which is a deal-break for performance. That's why the proposal in this thread uses the existing import mechanisms to define how the dependencies. (2) We also need a declarative, content-type agnostic primitive to express resource loads, such that the preload scanner is able to pickup and processes these fetches on par with all other resources -- hence my rel=preload suggestion. I don't disagree that we need a way to declarative way to import non-browser-native resources (like some text file the script uses for storing game level data or something). But I don't think we need a redundant mechanism to import resource types that already have existing import mechanisms. That's not a primitive, it's just a redundant mechanism. I went into more detail on this very topic, considering a wide array of options, in the big e-mail I sent recently: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html We can augment img, script, and other elements, with load-settings and other flags, but that still doesn't cover all the necessary cases. For example, how do I fetch a font file http://dev.w3.org/csswg/css-font-loading/ ...which presumably would have loadSettings exposed. or an arbitrary JSON payload with app-data, etc? XHR, or link rel=preload. I assume you're not expecting us to preparse the JSON file. Note that I'm looking for declarative syntax that allows me to set arbitrary fetch priorities - e.g. upgrade my JSON payload to high priority because I need it to render content on the screen. This is the part that we *need* to solve. rel=preload with the proposal on this thread handles this fine, as far as I can tell. Once we have the low-level declarative+imperative primitives for loading resources, we can build up all other loading and dependency patterns in app-space. That people have to build them in app space is the bug I'm trying to fix here. The loadpolicy/needs attributes are syntax sugar for select resource types -- nice, but (IMO) not strictly necessary and not sufficient for the more general case of content-types not covered by dedicated elements. needs= is actually very little more than syntactic sugar over ES6 module loader primitives, assuming that we can get the ES6 module loader to be augmented to address the needs of non-ES resources: http://esdiscuss.org/topic/es6-loader-proposed-changes -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Tue, 2 Sep 2014, Yoav Weiss wrote: On Sat, Aug 23, 2014 at 2:44 AM, Ian Hickson i...@hixie.ch wrote: [snip] load-settings=A JSON-encoded dictionary to pass to the Request constructor. I'm not a big fan of JSON attributes for this purpose Nobody is, as far as I know. It's just the least bad option suggested so far. Some of the alternatives we've discussed include: - a whole farm of content attributes -- pro: no mixed markup languages (JSON+HTML) -- con: lots of attributes instead -- con: leads to a situation where we have entirely different APIs in different cases (content attribute farm for HTML elements, some other API for non-elements) -- con: hugely increases (potentially in an unbounded fashion) the number of allowed attributes on many elements -- con: would have non-trivial document conformance rules (the attributes are probably interrelated, especially e.g. the ones for setting HTTP headers) -- con: ends up being really ugly and hard to use (how do you set the second HTTP header? It's not intuitive. How do you remove the first while leaving the second?) -- con: ends up even uglier if we ever need two sets on one element (e.g. one for poster= and one for src= on video, or one for each URL in a srcset=) - a new microsyntax, maybe CSS-like -- pro: can be optimised for the use case -- pro: can easily be given a dedicated API -- con: other than skipping the outer braces, it's not clear how much different it would end up being than JSON -- con: still results in mixed markup languages -- con: requires a custom parser -- con: language would have to be non-trivial since it has to include substrings (and escaping in those strings) and nested structures (e.g. for setting headers) - JSON -- pro: some extensibilty (so long as we just want a tree structure of strings and numbers, anyway) -- pro: existing standard syntax with off-the-shelf parsers -- pro: easily placed on other objects -- pro: easily duplicated if an element needs multiple Requests -- pro: can easily be given a dedicated API -- con: verbose -- con: mixed markup languages -- con: requires a non-trivial parser on the preloader thread What's the use-case that requires a Request constructor? Each Fetch has a Request. So assuming we want to explain the Web platform in terms of Fetch, we need a corresponding Request for each Fetch. The Request lets you control HTTP2 priorities and so forth. If so, maybe we can expose that only through JS initially, see what people use it for, and if it makes sense add it to markup later on? Well the Request object is only exposed through JS. But the Request object's construction parameters have to be exposed through markup because for many elements there's no time between the creation of the element and the creation of the Request passed to the Fetch. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need clarification on menu builder algorithm for contextmenu attribute
On Tue, 26 Aug 2014, Sanjoy Pal wrote: I feel the following statement for the third bullet of step 2, if the child is a menu element with no label attribute, Append a separator to the menu, then run the menu builder steps using this child menu element for the same menu, then append another separator to the menu. is contradicting the statement of step 3 Remove any submenu with no label, or whose label is the empty string, in the menu or any submenus. My understanding from the first statement is that the any child menu (submenu) with no label attribute should be flattened. But the subsequent statement implies removal of whole submenu. It's important not to confuse a child menu element with an actual submenu in the constructed menu. (This is similar to the difference between a section and a section.) There are two concepts here. Elements, including menu and menuitem, are your regular DOM element node. Pop-up menus, on the other hand, are lists of zero or more menu items, and menu items are commands, separators, and recursively other pop-up menus. When you have a child menu element with no label attribute, no submenu is created. The child menu items are inserted directly into the parent menu. So when it comes to the second statement quoted above, there's no submenu to remove. The second statement above could get triggered for something like menu label= (an empty label). I've tweaked the wording a bit to try to make this clearer. In particular I've made the terminology less ambiguous. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Preloading and deferred loading of scripts and other resources
. This plugin doesn't know or care that the other plugin also requests A.js. It doesn't know if there is a script element in the page requesting it or not, and it doesn't want to looking for it. It just wants to ask for A as a pre-requisite to C and D. But C and D have no dependency on each other, only a shared dependency on A. C and D should be free to run ASAP (in whichever order), assuming that A has already run [once] some user-interaction that initiates the load of A, C, and D. This user interaction may be before the other plugin requested A, or after it requested A. A.js can be requested relatively (via a base tag or just relative to document root) or absolutely, or it might be requested with the leading-// protocol-relative from, taking on whatever http or https protocol the page has, whereas other references to it may specify the prototcol. These plugins can't guarantee what ID's or classes they use are reliably unique without undue processing burden. [I've trimmed the text Kyle wrote here, but also implicit in his description, as I understood it, was that A.js should only run once even if both plugins tried to load it.] [Use-case T:] I have two different calendar widgets. I want to pop one of them up when a user clicks a button. The user may never click the button, in which case I don't want the calendar widget to have ever executed to render. [...] It'd be nice if both calendar widgets were built sensibly so that loading the code didn't automatically render. One of them IS, the other is unfortunately mis-behaving, and it will render itself as soon as its code is run. [...] Furthermore, these two widgets are not equal. Perhaps one is better for smaller browser window sizes, and the other is better for larger browser windows. [...] Regardless, the point is, there's run-time conditions which are going to determine if I want to execute calendar widget A or B, or maybe I never execute either. But I want them both preloaded and ready to go, just in case, so that if the user DOES need one, it's free and ready to execute with nearly no delay, instead of having to wait to request as I would with only on-demand techniques. [Use-case U:] I have a set of script A.js, B.js, and C.js. B relies on A, and C relies on B. So they need to execute strictly in that order. [Now], imagine they progressively render different parts of a widget. [...] I only want to execute A, B and C once all 3 are preloaded and ready to go. It's [...] about minimizing delays between them, for performance PERCEPTION. [For example, one of them might start playing a video, and another might introduce the canvas slides for that video. You want all of the relevant scripts to be run at once, so there's no point where the page has a video element but doesn't have the canvas.] On Thu, 11 Jul 2013, Kyle Simpson wrote: [Use-case V:] you have a string of scripts (A.js, B.js, and C.js) loading which constitute a dependency chain. A must run before B, which must run before C. However, if you detect an error in loading, you stop the rest of the executions (and preferably loading too!), since clearly dependencies will fail for further scripts, and the errors will just unnecessarily clutter the developer console log making it harder to debug. [Use-case W:] some developers have even requested to be able to stop the chain and prevent further executions if the script loads, but there's some compile-time syntax error or run-time error that happens during the execution. For them, it's not enough for B to simply finish loading successfully, but that it must fully execute without error. On Sun, 14 Jul 2013, Kornel Lesi��ski wrote (trimmed): [Use-case X:] not all dependencies are JS files, e.g. authors use plugins to load template files, JSON, images, etc. [Use-case Y:] not all dependencies are usefully satisfied immediately after their JS file is loaded, e.g. some libraries may need asynchronous initialization. [Use-case Z:] Another common kind of dependency scripts have is presence of certain element in the DOM, e.g. `dropdown-menu.js` may require `nav id=menu` to be in the document _and_ have its content fully parsed before the script can run. On Tue, 27 Aug 2013, Ian Hickson wrote: Jake also mentioned these requirements: | - Provides an adoption path for browsers that don't support the new | feature (happy for the fallback to be blocking document-order | execution) | - Is discoverable by pre-parsers (so async=false and old-IE's | readystate methods aren't enough) And Kyle mentioned this scenario that we need to handle as well (not strictly a use case, more a variant on the above use cases): I want to preload a script which is hosted somewhere that I don't control caching headers, and to my dismay, I discover that they are serving the script with incorrect/busted/missing caching headers
Re: [whatwg] Memory management problem of video elements
On Wed, 20 Aug 2014, Philip Jägenstedt wrote: I don't know, but would guess that not all media frameworks can seek to an exact audio sample but only to the beginning of a video frame or an audio frame, in which case currentTime would be slightly off. One could just lie about currentTime until playback continues, though. Note that setting currentTime is required to be precise, even if that means actually playing the content in silence for a while to get to the precise point. To seek fast, we have a separate fastSeek() method. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Mon, 11 Aug 2014, Ilya Grigorik wrote: On Mon, Aug 11, 2014 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Any bugs or threads that I can follow to track progress? I'd love to help if I can. My understanding of ES6 is mostly being helped by discussions on #whatwg and e-mail threads to es-discuss. Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. Preload is straight forward, sure. How much does preconnect within a page actually help? Isn't just declaring the URLs enough? I don't really see how you expect this to be used or exposed. For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. The ability to tell a page what subsequent resources will be necessary (prerendering) seems pretty straight-forward too, sure. That's mostly a solved problem with rel=prerender, no? Anything we add to make fetching more powerful will automatically be exposed to that too, presumably. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
On Thu, 14 Aug 2014, Ilya Grigorik wrote: Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. It would be great to get a set of use cases describing what your proposal is addressing, since that would more easily let people evaluate whether it's worth doing, and if so, whether this proposal does it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Fri, 15 Aug 2014, Ilya Grigorik wrote: - link href='https://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' - above stylesheet is dynamic and returns a pointer to a UA optimized font file that lives on https://fonts.gstatic.com Ah, yeah, that's an excellent example. Thanks. That said, I think we're on the same page... I'm just arguing that X will subsume resource hints is not entirely true: we still need to define how preconnect/preload/prerender need to behave, which APIs they will expose, what guarantees they will provide, and so on. None of that is currently spec'ed, which is the gap I'm trying to fill. I totally agree that more detailed specs for rel=prerender, rel=preconnect, and rel=prefetch/preload/subresource would be useful. I may end up speccing the latter, but what I'm doing doesn't so far have any direct impact on the former two. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Thu, 7 Aug 2014, Ilya Grigorik wrote: I'm working on the resource hints spec we've been discussing on public-webperf... FYI, I'm currently working an a dependency system update to HTML which has the goals of: - merging HTML import dependency management and ES6 module dependency management infrastructure - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts - hooking most HTML loading contexts into the new Fetch API Assuming this works out as intended, it would completely subsume the resource hints proposal. My main blocker right now is the part where it gets integrated into the ES6 module system; it's requiring some very careful reading of the ES6 spec. I'm still in the middle of this. You can see my current results here: http://www.gliffy.com/go/publish/6040024 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Mon, 11 Aug 2014, Ilya Grigorik wrote: Will this result in API that extends beyond import and ES6 module use cases? For example, I want to have the building blocks that will allow me to declare these dependencies on my own: these two images before that script, but after this stylesheet, oh and that stylesheet should have higher priority than... We can express all of this in HTTP/2, and I'd like that to be surfaced to the developers as a first class API. Yeah, this is the kind of thing I'm looking at. - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts I'm looking at the gliffy The gliffy is just a description of the ES6 module system. but having a hard time understanding how this will work... You and me both. It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) All of that is out of scope of ES6 (and thus the gliffy), but is what I'm trying to design. I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. Do you mean the case of fetching a file before you've loaded the base HTML file, as in loading a landing page before the user has selected a search result on a search engine, for example? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Accept header
On Wed, 30 Jul 2014, Anne van Kesteren wrote:
it would be desirable to have Accept / Accept-Language be set by APIs,
such as img. XMLHttpRequest already does this (unless a developer
added those headers), see http://xhr.spec.whatwg.org/
If we are eventually going to expose something like a Fetch object for
each API that can issue a fetch it would seem best if these details were
defined at the API-level.
I guess for now I'll add some notes to the network-level bits of Fetch
to indicate Accept / Accept-Language cannot be set at that point by the
user agent.
There's three ways that I see:
1. Expose it on a fetch object available from all the places that can
do fetches. (HTMLImageElement, XMLHttpRequest, StyleSheet, etc)
var img = new Image();
img.src = 'foo.png';
img.fetch.doWhateverWithTheAcceptHeader('foo');
2. Expose a dedicated attribute on relevant elements, that sets the
default fetch settings, either using some generic syntax:
img src=foo.png fetchoptions={whatever:{accept:'foo'}}
...or some nicer dedicated syntax:
img src=foo.png fetchoptions=accept: foo; whatever: bar
3. Have multiple dedicated attributes:
img src=foo.png accept=foo whatever=bar
These are not mutually exclusive.
I would avoid adding the non-API sugar versions (content attributes,
especially the dedicated ones) for anything that didn't have significant
compelling use cases.
Note that Accept _should_ probably be set by the UA for images, since
the author can't know what image types are supported.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, 28 Jul 2014, Anne van Kesteren wrote:
On Wed, Jul 23, 2014 at 2:33 AM, Ian Hickson i...@hixie.ch wrote:
Why not:
var mystyle = E('link', { rel: 'stylesheet', href: 'my.css', whenneeded:
true });
document.body.appendChild(mystyle);
var myfetch = mystyle.fetch;
...
...where E() is some mechanism to easily create new elements (we need
one of those regardless), and whenneeded is some attribute that controls
the load policy (and in this case, tells it to not load yet, since I
presume that's what you're going to do next with the myfetch variable)?
Because that does not give you access to the additional parameters of
Fetch: http://fetch.spec.whatwg.org/#requestinit (And this will grow
with parameters such as omitReferrer.)
Why would you not be able to set them on the myfetch variable in the
snippet above?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, 28 Jul 2014, Anne van Kesteren wrote:
On Mon, Jul 28, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 28 Jul 2014, Anne van Kesteren wrote:
On Wed, Jul 23, 2014 at 2:33 AM, Ian Hickson i...@hixie.ch wrote:
var mystyle = E('link', { rel: 'stylesheet', href: 'my.css',
whenneeded: true });
document.body.appendChild(mystyle);
var myfetch = mystyle.fetch;
...where E() is some mechanism to easily create new elements (we need
one of those regardless), and whenneeded is some attribute that controls
the load policy (and in this case, tells it to not load yet, since I
presume that's what you're going to do next with the myfetch variable)?
Apologies for missing myfetch. That could work potentially. Not
entirely sure what kind of object it would return, but I guess we can
think of something.
It would presumably return the same object that was being proposed for the
other way around (the proposal where you call as_stylesheet or whatever).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, 28 Jul 2014, Ben Maurer wrote: What about initial parameters to fetch (vs modifications you could make in flight via the myfetch object). Would there be an attribute of link that you could use to pass parameters to fetch (eg a custom header)? What's the use case here? Why are we trying to send custom headers on a link? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, 28 Jul 2014, Ben Maurer wrote: The idea is you could specify any parameter to fetch. For example, if fetch allowed you to specify an HTTP/2 priority, you could specify that. As a concrete example of why passing a header might be useful, Facebook uses an automated pipeline to decide what CSS/JS files to package together. If we could pass a custom header in the request for a CSS file (for example: what part of the page caused that file to be loaded) we could use this information in our packaging system to make smarter decisions. While we do have the referrer header, a piece of interactive javascript on a page might be the cause of the CSS file being required. A custom header would allow logging this. Ah, I see. Makes sense. Are there any cases where you'd know the headers you want to send at the time the markup is written, before JS is involved, or would you always be updating the fetch settings from script? Would this ever apply to things that are downloaded with the initial load, or even in the preloader, or is this only for loads that are triggered by script later? We can definitely expose the fetch settings in markup, e.g. in the trivialest sense just by embedding a JSON blob in an attribute, or maybe in a more friendly dedicated microsyntax. I just want to make sure that that's the right thing to do before we go down that path -- meaning, that it has sufficient use cases to justify it, rather than require consumers to set these settings from script. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, 21 Jul 2014, Ben Maurer wrote:
(1) Allowing the user to specify parameters to Fetch. For example, a user
could say:
script src=/my.js params={'headers':{'myheader':'value'}}
id=myscript /
This would allow the user to make any type of request customization that
they could for a direct call to Fetch.
I think this would make a lot of sense. It's similar to earlier
suggestions for controlling Referer on a per-link basis, but more
generic. The problem I had with the proposals for controlling Referer was
that while there's an obvious way to do it for script and link, it
quickly starts breaking down don't have a 1:1 mapping of URL to element.
For example, how do you get the fetches of URLs in a style sheet? Or of
the poster frame of a video element? Or EventSource objects? Should we
just have different ways to set the options for each one?
(2) Allowing the user to access the in progress fetch object. For
example, a user could say:
$(myscript).fetch.then(function(resp) { console.log(resp.status); })
Over time, the fetch object might add new functionality that would be
useful to the application developer. For example, I could imagine the
fetch object gaining a way to change HTTP/2 priorities mid-request.
Developers could take advantage of these functions for browser-initiated
fetches.
This would make sense to me also, but has the same API explosion problem
where there's no obvious way to expose this consistently for everything.
(3) Allowing the user to construct a script or stylesheet from a fetch.
Complex sites often want precise control over when scripts and
stylesheets are loaded and inserted into the DOM. For example, today
inserting a stylesheet blocks the execution of inline script tags. Some
sites may know that this dependency is not needed.
This specific use case is something I'm already working on. My long-term
plan is to integrate something like this with the HTML Imports dependency
model and the ES Module dependency model so that we have a single model
that can handle everything.
If one could construct stylesheets and scripts directly from a fetch,
the author could separate the act of fetching the stylesheet from
inserting into the DOM:
If we have a way to give dependency information for the link or
script, we don't need to manually manage the dependencies at the Fetch
object level.
var myfetch = window.fetch(...);
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
By calling asStyleSheet, the user could preserve the devtools experience
that exists today while still having complete control over the fetching
of their content.
We could do this too. It's mostly just a convenience method, right?
(4) Giving the user explicit access to initiate fetches from the preload
scanner. One downside of the approach in (3) is that it doesn't take
advantage of the preload scanner to initiate fetches. I could imagine
offering the user an explicit way to trigger a Fetch from the preload
scanner:
link id=foo rel=fetch href=/my.css /
$('foo').then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
This is exactly the kind of thing I'm looking at addressing with the
aforementioned work on dependencies.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Tue, 22 Jul 2014, Ben Maurer wrote:
To follow this up with a concrete suggestion:
var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
...
Why not:
var mystyle = E('link', { rel: 'stylesheet', href: 'my.css', whenneeded:
true });
document.body.appendChild(mystyle);
var myfetch = mystyle.fetch;
...
...where E() is some mechanism to easily create new elements (we need
one of those regardless), and whenneeded is some attribute that controls
the load policy (and in this case, tells it to not load yet, since I
presume that's what you're going to do next with the myfetch variable)?
(whenneeded here is a placeholder. I don't expect to actually go with
that. I just used it because it's what I had proposed the last time this
came up.)
That seems like it'd be no more complicated, but would involve less new
API surface (not to mention fewer new ways to shoot yourself in the foot,
e.g. getting the 'fetch-as' value wrong), and wouldn't require us to come
up with a way to enumerate all the kinds of fetch in an API.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at this in more detail in due course, but FWIW this appears to
be more or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
On Mon, 14 Jul 2014, Adam Barth wrote: The difference is that window.open opens a new browser window even if the URL is handled by an external protocol handler. Even if we changing current browsers to detect whether the URL will be handled by an external protocol handler before opening the window, web sites won't be able to feature-detect which browsers have this new behavior and therefore won't be able to move away from iframe@src hacks until all the browsers they care about have the behavior change. By contrast, sites can feature detect navigator.launchURL and fall back to iframe@src in UAs that lack the new API. I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
On Mon, 14 Jul 2014, Adam Barth wrote: I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius It doesn't really matter how long it takes. The time until authors can stop using the iframe hack is the same whether we provide a new API or have a legacy API that needs updating to be slightly less annoying. If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stricter data URL policy
On Wed, 9 Jul 2014, Jonas Sicking wrote: But javascript: is sort of screwed no matter what. A javascript URL inheritely will run javascript, and it always does so in the origin of whoever set the url. So pages will have to look for javascript: anytime they are handling URLs. But it's better if pages only have to look for javascript: when handling URLs. Rather than having to look for javascript:, data:, blob: and nextbigthing:. I'd love to simply deprecate javascript:. It doesn't seem like the use cases are worth the complexity for both implementations and authors. But I think it's too commonly used these days to get rid of. At least for quite some time. About 100x the usage of sync XHR if [1] means that I guess it means. Note that 'javascript:' at this point is about as deprecated as I think we can get it. It's just special-cased logic in the navigation algorithm. Everywhere else, it just gets treated as an unknown URL scheme. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hit regions: exception when the region has no pixels
On Wed, 2 Jul 2014, Rik Cabanier wrote: The canvas spec [1] currently states: If any of the following conditions are met, throw a NotSupportedError exception and abort these steps: ... The specified pixels has no pixels. Since the specified pixels are the union of the clipping path and the current path, it will be nearly impossible for an author to determine if a hit region has no pixels. Can't we relax this requirement and simply not set up a new hit region if there are no pixels? Yeah, that seems reasonable. Please assume that the spec is so adjusted. (I'm in the middle of updating my pipeline, so I can't easily make any spec edits right this second. Sorry about that, everyone. I promise I'll be getting back to my old productive rate of response as soon as the pipeline is back up and running!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SVG cloning elements from HTML5
On Tue, 24 Jun 2014, Robert O'Callahan wrote: !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. As siblings of the svg element, though, not descendants. This was required to get some level of compatibility with deployed content while still allowing svg in HTML. There was content out there that, for reasons that defeat me, had svg start tags (but not end tags). If we had not introduced this limited trap door out of the foreign lands (it's a hard-coded list of tag names that bail out in this way), it would have caused the pages to be blank from the svg start tag to the end. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] brand-color meta extension
On Thu, 26 Jun 2014, Tao Bai wrote: Hi, I have added brand-color meta extension in http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your comment on it. Please check the detail on linked spec. The cited spec mentions mapplication-navbutton-color and apple-mobile-web-app-status-bar-style. Why don't we just register and use those? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] brand-color meta extension
On Thu, 26 Jun 2014, Tao Bai wrote: The brand color is super set of them and not limited to use in the navbutton or status bar, furthermore, not all browsers have navbutton or status concept, it makes developer confused. I don't think it confuses authors any more, and possibly a lot less, than having three ways to do essentially the same thing. The msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are prefix and browser specific, brand-color is general and could be standard for all browsers. That the keywords are prefixed is a mistake made by the relevant vendors, but I don't think it should stop us from using them if they are appropriate. Looking at those two keywords more closely, it seems that apple-mobile-web-app-status-bar-style wouldn't work because it doesn't take a CSS colour, it takes some specific keywords. However, msapplication-navbutton-color, and, maybe better, msapplication-TileColor, seem like pretty good fits to me. I don't really understand why one would avoid just reusing those, either instead of, or at least as well as, a newer more generic term. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Update and info!
On Thu, 26 Jun 2014, Anne van Kesteren wrote: On Thu, Jun 26, 2014 at 7:36 PM, L2L 2L emanuelal...@hotmail.com wrote: Could/is there [be] a mailing list that send out information on new updates on HTML tags, etc. and more? There's https://twitter.com/whatwg There's also a ton of GitHub repositories you can watch: https://github.com/whatwg/ (some also have an associated Twitter account). You can also subscribe to the spec itself to get update notifications; see the top left of the spec at: http://whatwg.org/html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] `brand-color` meta extension
On Thu, 26 Jun 2014, Tab Atkins Jr. wrote: On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: This feature has been developed in the past under multiple proprietary names, such as mapplication-navbutton-color for Internet Explorer and apple-mobile-web-app-status-bar-style for Mobile Safari. Authors MUST NOT use the proprietary variants of this meta extension. User agents that support proprietary variants of this meta extension must, if brand-color is specified, use brand-color for these purposes, and ignore any proprietary variants. In another thread, Hixie asks why we don't just standardize these proprietary variants. I think because they're horridly named is a sufficient answer, but there's a weaker proposal inside of that which I think is potentially valid: should we define that msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are required-support variants? This requires a bit of additional parsing work, but it's not a big deal: * msapplication-navbutton-color only allows named and hex colors. * apple-mobile-web-app-status-bar-style appears to accept the values default, black, and black-translucent, which we can define as meaning, respectively, that the page has no brand color, that the brand color is black, or that the brand color is rgba(0,0,0,.5) (spitballing here, if someone can provide the real alpha that would be great). I think it would make sense to allow vendors to treat these all as independent values (in particular, we wouldn't want IE to be forced to extend their interpretation of msapplication-TileColor and msapplication-navbutton-color to be redundant), but I do think it would make sense to encourage UAs to draw colours from whichever values are provided, so that authors don't have to include different values for each browser. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Missing HTMLSelectElement.autocomplete
On Wed, 4 Jun 2014, Matthew Noorenberghe wrote: Is it intentional that there is no HTMLSelectElement.autocomplete IDL attribute? Both input and textarea have it so there is currently inconsistency. Woops. Totally an oversight on my part. When I added autocomplete to select recently, I forgot to fix that. Fixed. Thanks. On Wed, 4 Jun 2014, Luis Farzati wrote: I would like to insist on the datalist proposition I posted on this list (didn't caught any interest, though). A datalist for select would enable to have the contents of a select defined externally, and would also enable the reuse of this data. I don't see why datalist can be applied to an input and not to a select. Don't worry, your e-mail is in the queue! Requests for features tend to take a bit longer for me to deal with than simple bug reports, though. On Wed, 4 Jun 2014, Dan Beam wrote: It'd be nice to avoid more attribute accessors (and encourage authors to use getAttribute() instead), but if input and textarea have them we should probably be consistent. Can you elaborate on the cost of attribute accessors? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Missing HTMLSelectElement.autocomplete
On Wed, 4 Jun 2014, Dan Beam wrote: On Wed, 4 Jun 2014, Dan Beam wrote: It'd be nice to avoid more attribute accessors (and encourage authors to use getAttribute() instead), but if input and textarea have them we should probably be consistent. Can you elaborate on the cost of attribute accessors? Namespace exhaustion (maybe form.autocomplete() would've worked instead of requestAutocomplete() if autocomplete= hadn't taken it?) I think it would have been very confusing to have a method with the same name as a content attribute. multiple ways to do things (vs getAttribute) Well sure, but isn't the IDL attribute a lot cleaner-looking? longer specs/IDLs/compile times. Surely authors' needs outweigh these. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stricter data URL policy
On Mon, 2 Jun 2014, Anne van Kesteren wrote: At the moment data URLs inherit the origin of the context that fetches them. To be precise, the origin of data: URLs themselves is the unique origin. It's the origin of resources that come from data: URLs that's different. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] I take back my request for this instead. SVG API
On Sat, 24 May 2014, Emanuel Allen wrote: SVG API for the canvas element, simple call svg; var ctx = canvas.getContext(svg); How would this work? Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] @autocomplete sections
-* at all before worrying about how rAc() works with them. On Wed, 14 May 2014, Ilya Sherman wrote: It likely makes sense to remove section-* tokens from the spec entirely. I'm not sure how much they're used, but I would guess almost not at all. It would be nice to have some concrete numbers; but unfortunately, I'm not aware of any metrics tracking the usage of section-* tokens. I agree that they're probably not used much, but I think it makes sense to support them because without them a form can basically not use autocomplete= at all for any fields that have duplicates. There's plenty of cases where autofill for subsets of a form makes sense and would be possible, but where without section-* the autofill would just be confused. It doesn't seem to me that, outside of rAc(), section-* has much of an implementation burden. It's essentially just a way to split the form into subforms for the purpose of autofill only. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebGL and ImageBitmaps
On Fri, 16 May 2014, Justin Novosad wrote: This is a longstanding issue with 2D canvas that several developers have complained about over the years. The color space of the canvas backing store is currently unspecified. It's defined that the colour space must be the same as used for CSS and img, but yeah the final colour space is left up to the UA: http://whatwg.org/html#color-spaces-and-color-correction Blink/WebKit uses output-referred color space, which is bad for some inter-op cases, but good for performance. Calling drawImage will produce inter-operable behavior as far as visual output is concerned, but getImageData will yield values that have the display color profile baked in. I'm not quite sure what you mean here. If you mean that you can set 'fillStyle' to a colour, fillRect the canvas, and the get the data for that pixel and find that it's a different colour, then that's non-conforming. If you mean that you can take a bitmap image without colour-profile information and draw it on a canvas and then getImageData() will return different results, then again, that's non-conforming. If you mean that drawing an image with a color profile will result in getImageData() returning different colour pixels on different systems, then that's allowed, because the colour space of the canvas (and the rest of the Web platform, which must be the same colour space) is not defined. Some web developers have worked around this by reverse-engineering the client-specific canvas to sRGB colorspace transform by running a test pattern through drawImage+getImageData. It is horrible that we are making devs resort to this. I'm not really sure what this work around achieves. Can you elaborate? If you just want to do everything in sRGB, then putting all your images in sRGB but without giving color space information (or setting the option to 'strip', if we add these createImageBitmap() options) would result in what you want, no? You'd have to manually (or on the server) convert images that were in other colour spaces, though. Adding a colorspace option to createImageBitmap is not enough IMHO. I think we need a more global color-management approach for canvas. If we need colour management, we need it for the Web as a whole, not just for canvas. So far, though, implementations have not been implementing the features that have been proposed, so...: http://www.w3.org/TR/css3-color/#dropped -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] type=month-day
On Mon, 17 Mar 2014, Anne van Kesteren wrote: As a heads up, Mozilla is considering an experimental implementation of month-day (mobile only so far) for entering birthdays and such: https://bugzilla.mozilla.org/show_bug.cgi?id=974341 However, it might be even better for birthdays if the year part became optional rather than always omitted. Original motivation is here http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027725.html by Tantek Çelik. Relatedly, there was a suggestion filed on the spec once to introduce an input type that allowed users to enter date/time data where they could fill in either , -MM, -MM-DD, etc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114 This is not quite the same, but worth considering as well. I've filed this bug to track the spec side of MM-DD: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25742 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebGL and ImageBitmaps
On Wed, 14 May 2014, Kenneth Russell wrote: On the assumption that they are, I filed some bugs to cover this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25642 createImageBitmap() options: image data orientation https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643 createImageBitmap() options: color space handling https://www.w3.org/Bugs/Public/show_bug.cgi?id=25644 createImageBitmap() options: alpha channel handling As usual with such bugs, if there is interest amongst browser vendors in implementing any of these, please comment on the bug. For the record, I've commented on the above bugs. I'd personally like to see them all specified and implemented so that image loading for the purpose of uploading to WebGL textures can be more efficient. I see that your comment was that the WebGL WG would like them specified. Does your saying that mean that Chrome wants to implement these also? Just having a working group want them specified doesn't help get us to multiple implementations... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On Tue, 13 May 2014, Dirk Schulze wrote: contentEditable can be fairly useful in SVG as well. It partly works for inline SVG content in web browsers today. The question is, should SVGElement add support for contentEditable/isContentEditable and add it to its interface? Or should both attributes move to the Element interface instead? I would be very careful about moving global attributes to Element. Doing so implies that we are adding them to _all_ XML namespaces. That's a huge change to propose. Even with class it's IMHO going a bit far (we're saying that the semantics of myvocab:teacher class=.../ are that it's a space-separate list of CSS class names, even if the vocab designer intended it to be a room name or whatever). I would feel more comfortable putting things on SVG, MathML, and HTML explicitly. BTW, if anyone wants to move contenteditable= to another spec, my suggestion would be that the place to move it to is the HTML Editing APIs spec, which could be renamed Web Editing APIs. There's precedent for having hooks for attributes like that, e.g. ARIA. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote: On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote: Note that there _is_ still a content type check with appcache, it's just done on the first few bytes of the file instead of on the metadata. (This is IMHO how all file typing should work.) This seems to imply MIME types should always be ignored, is that actually the case? Only for Appcache and other formats that have unambiguous signatures, like PNG, GIF, etc. I mean, it's clearly possible to have a file that is both, valid CSS and valid JS. CSS, JS, HTML, etc, are IMHO poorly designed text formats, since they don't have a defined fixed signature. So for those, we need Content-Type. (The Content-Type is a bit of a red herring here. If you can prevent the attacker from overriding the Content-Type, you can prevent them from sending the appcache signature also.) The author feedback that made the CT check to be dropped is that it was too hard for authors to set CT, but it was easy to set the appcache signature. The attacker will usually have the same (and more) constrains than what the author has (although, attackers might be more tech savy than their victim site owners in some cases). In usual (and complex) web applications, it's not as common to be able to set the Content Type as it is to be able to control the first few bytes (think JSONP endpoints for example - but exporting data in text format is another example). I agree that you're less likely to be able to control the headers. But I don't think that's enough. A big part of the reason that authors find it hard to set HTTP headers is that doing so is technically complicated, not that it's impossible. If an attacker is putting files on an Apache server because there's some upload vulnerability, it becomes trivial to set the HTTP headers: just upload a .htaccess file. My point, though, was from the other angle. If you can _prevent_ someone from setting HTTP headers somehow, you can equally prevent them from uploading files that match a signature. In any case, requiring HTTP headers for appcache was very poorly received. I don't think we should return to requiring them. Aside from the fact that it would break a lot of sites, it would also mean ignoring pretty clear author feedback. Cookie Bombing (causing the user agent to send an HTTP request that's bigger than the server accepts) should IMHO be resolved by setting an upper limit on what clients can send in cookies, and having user agent enforce this limit. Server would then know that they need to support that much and no more for cookies. Yes, I agree. This was an example of a simple client DoS attack. Is fixing Cookie Bombing being tracked by anyone? On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote: One idea is with a special CSP policy that forbids manifest files from working without the right CT I don't think limiting it to Content-Types is a real fix, but we could mark, with CSP, that the domain doesn't support appcache at all. The problem I see with the CSP approach is that only pages that have CSP will be protected. Well, that's true of anything involving CSP. We could, though, say that a manifest can only do fallbacks for URLs that are within the subpath that the manifest finds itself in. That would be an interesting way of scoping manifests on shared domains. This is how crossdomain.xml works, so it might make sense. But I'm not sure if that would be sufficient. Well, all of this is defense in depth, essentially. So strictly speaking none of it is necessary. Obviously the deeper the defense, the better; but we shouldn't go so deep as to make the feature unusable. (I mean, we could have really _good_ defense by just dropping the feature entirely.) So, moving forward, what do we want to do? Should I add the path restriction to fallback? (Is that compatible enough? Do we have data on that?) Should we add CSP directives for this? Something else? Are the lessons learnt here being reported to the Service Worker team? On Mon, 12 May 2014, Michal Zalewski wrote: Yup, from the perspective of a significant proportion of modern websites, MIME sniffing would be almost certainly a disaster. I'm not suggesting sniffing, I'm suggesting having a single well-defined algorithm with well-defined fixed signatures. For formats that don't have signatures, this doesn't work, obviously. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Michal Zalewski wrote: We probably can't support a well-defined algorithm for detecting documents that have distinctive signatures while safely supporting formats that don't have them (because there is always a possibility that the non-structured format with user-controlled data could be used to forge a signature). Right. You'd have to check the Content-Type header first. On Tue, 13 May 2014, Michal Zalewski wrote: In general, in the past, in pretty much every single instance where browsers tried to second-guess Content-Type or Content-Disposition headers - be it through sketchy proprietary content-sniffing heuristics or through well-defined algorithms - this ended up creating tons of hard-to-fix security problems and introduced new burdens for web developers. It looks elegant, but it's almost always a huge liability. I disagree. Much of the Web actually relies on this today, and for the most part it works. For example, when you do: img src=foo ... ...the Content-Type is ignored except for SVG. I think that most or all browsers are moving pretty firmly in the other direction, enforcing C-T checking even in situations that historically were off-limits (script, style, object, etc), based on strong evidence of previous mishaps; to the extent that the spec diverges from this, I suspect that it will be only a source of confusion and incompatibility. Actually as far as I can tell we're converging on a hybrid model, more or less the one specified here: http://mimesniff.spec.whatwg.org/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: I agree that you're less likely to be able to control the headers. But I don't think that's enough. A big part of the reason that authors find it hard to set HTTP headers is that doing so is technically complicated, not that it's impossible. If an attacker is putting files on an Apache server because there's some upload vulnerability, it becomes trivial to set the HTTP headers: just upload a .htaccess file. Uploading a .htaccess file is a significantly greater vulnerability than XSS, as it allows RCE, and we are concerned here about vulnerabilities that don't just allow the user to upload files, but rather to serve files from a web service. The later are more common than the former. It doesn't necessarily allow RCE, but sure. My point, though, was from the other angle. If you can _prevent_ someone from setting HTTP headers somehow, you can equally prevent them from uploading files that match a signature. It's not that simple, it's not just about uploading files, it's about serving content that looks like manifest files, but actually aren't. Similar to XSS (note the docs attached to my OP like http://www.cse.chalmers.se/~andrei/ccs13.pdf for examples). Well, you have to upload two files for this vulnerability, right: an HTML file with a manifest= that points to the manifest, and the manifest itself. Both are things that could be detected. Of course, the assumption is that there's a vulnerability in the first place, so we can just assume that any mitigations to detect these uploads are also broken... The reason I was initially talking about detecting these files is that I was imagining a situation where there was a site used for shared static hosting, where one of the people legitimately uploading files was (intentionally or not) causing the whole domain to get caught in their manifest's fallback rule. In that situation, one can just block all manifests by scanning for them (or for HTML files with manifest= attributes). Also, in those situations, MIME type checks are less likely to be helpful since you'd need to give these users the ability to set MIME types. For this kind of situation, path restrictions would work well, I think, assuming you isolate each user to a different path. But in the case of arbitrary upload vulnerabilities, I agree that these mitigations are moot. In the case of arbitrary upload vulnerabilities, I don't really think any solution is going to be convincing short of dropping the FALLBACK feature, because fundamentally being able to capture the entire domain to persist the existence of content into the future when it's no longer being served is the entire point of the feature. Cookie Bombing (causing the user agent to send an HTTP request that's bigger than the server accepts) should IMHO be resolved by setting an upper limit on what clients can send in cookies, and having user agent enforce this limit. Server would then know that they need to support that much and no more for cookies. Yes, I agree. This was an example of a simple client DoS attack. Is fixing Cookie Bombing being tracked by anyone? This would be in IETF I assume? I don't know how that process works, we can follow up offline. We should make sure this is indeed followed up upon. Before we add changes, let's figure out what's the best path forward. I think that's a reasonable proposal, but I am hoping we can come up with a better one, as I don't feel it's yet sufficient. Ok. Let me know when you want me to change the spec. :-) Are the lessons learnt here being reported to the Service Worker team? Yup, who is that? I believe Alex Russel is the point person on that technology. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: Thanks! Just to ensure this wasn't lost in the thread. What about X-Content-Type-Options: nosniff? Could we formalize it and remove the X and disable sniffing all together? Do you mean for manifests specifically, or more generally? For manifests specifically, it seems like a very odd feature. Manifests don't have a MIME type normally, but if served with this header, then you should also change how you determine if a manifest is a manifest? If we just want a way to prevent pages that aren't supposed to be manifests from being treated as manifests, I think it'd be better to have a CSP directive that disables manifests. Then you would apply it to any resource you know you don't want cached, don't want to be treated as being able to declare a manifests, and don't want treated as a manifest. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote: Now, with appcache manifest files, we are introducing a security-sensitive change based on a file with special powers (more on this later), and while before they were guarded by a Content-Type check, this isn't the case anymore. Note that there _is_ still a content type check with appcache, it's just done on the first few bytes of the file instead of on the metadata. (This is IMHO how all file typing should work.) 1. When there is an XSS in your favorite website, and you are infected with it. Thanks to FALLBACK the attacker can make it so that you can never recover from the XSS (and be infected for ever). The way to do this is by finding an endpoint in the vulnerable web application that lets you generate a file that looks like a manifest file (this isn't hard - really), and then force the browser to use it via your XSS. I don't really see a way to really fix this short of dropping FALLBACK support entirely. (The Content-Type is a bit of a red herring here. If you can prevent the attacker from overriding the Content-Type, you can prevent them from sending the appcache signature also.) The way you make sure FALLBACK triggers every time (and not just when the user is offline) is by means of Cookie Bombing. While similar attacks were already possible before via other mechanisms such as localStorage and the FileSystem API and such, they were always kept at bay, and this makes things worse. Cookie Bombing (causing the user agent to send an HTTP request that's bigger than the server accepts) should IMHO be resolved by setting an upper limit on what clients can send in cookies, and having user agent enforce this limit. Server would then know that they need to support that much and no more for cookies. 2. CDNs and similar sites can be completely taken over for all the HTML hosted in them. They will effectively break and reach an irrecoverable state. While this isn't the case for resources like JS files, HTML files enough are already a concern. When you're online, only resources that actually specify the given manifest can be taken over. One idea is with a special CSP policy that forbids manifest files from working without the right CT I don't think limiting it to Content-Types is a real fix, but we could mark, with CSP, that the domain doesn't support appcache at all. or by means of per-page suborigins I don't know that we need to go to that length. We could, though, say that a manifest can only do fallbacks for URLs that are within the subpath that the manifest finds itself in. That would be an interesting way of scoping manifests on shared domains. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] APIs inside Workers
Some old e-mails regarding exposing APIs in Workers... On Thu, 14 Mar 2013, Tobias R. wrote: I can see efforts in exposing canvases within a worker [1]. Does that mean the following APIs are exposed and available within a worker as well? Since you sent that e-mail, I updated the spec to use the new Exposed WebIDL annotation to say what is exposed in workers. - CanvasPathObject [2] Assuming you mean Path2D, yes. - SVGMatrix See: Path#addPath [3] That's up to the SVG folk, but presumably yes. On Tue, 9 Apr 2013, Rik Cabanier wrote: It's unclear at this point how fonts would be resolved in the canvas path object. If this did not yet get resolved, please let me know. On Thu, 14 Mar 2013, Simon Pieters wrote: The new canvas proxy stuff is supposed to make canvas work in workers, but I don't see any normative text that makes the necesary interfaces and constructors actually available in workers. The spec needs to explicitly say that CanvasRenderingContext2D, e.g., is to be available in workers. This is now done, using [Exposed=...]. On Tue, 9 Apr 2013, Rik Cabanier wrote: Is there a list somewhere that lists all the interfaces that are available to a worker? I don't think it's listed explicitly in one place currently, no. (This information is spread across many specs, so generating an up-to-date list would be non-trivial.) On Wed, 10 Apr 2013, Boris Zbarsky wrote: We should solve this problem. At this point we have some interface and prototype objects that should only appear on Window, some that should only appear in Workers and some that should appear both places I wonder whether it makes sense to specify in the IDL which kind the interface is. This is how we ended up doing it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] WebGL and ImageBitmaps
or pixel data access. It's okay if it's immutable, and it's okay if constructing one from an img or a Blob takes time, as long as once I have an ImageBitmap I can use it to render and use it to extract pixel data without user configuration/hardware producing unpredictable results. This seems reasonable, but it's not really detailed enough for me to turn it into spec. What colour space? What exactly should we be doing to the alpha channel? On Wed, 17 Jul 2013, Justin Novosad wrote: I am wondering why it is important for image elements to be loaded. Is it in case the image element goes out of scope or the src attribute changes before the load completes? If that is the issue, the implementation can workaround that internally to ensure that the ImageBitmap is created from whatever resource was referenced by the source image when createImageBitmap was called. I think it would be nice to be able to avoid the JS red tape associated with chaining two async events (image onload - createImageBitmap). The limitation is mostly just for simplicity in defining and implementing the API. I agree that it could be changed. I've filed this bug to track this, if implementors want to support createImageBitmap() from a non-loaded img (waiting for the load to complete) then please comment on the bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25634 On Wed, 17 Jul 2013, K. Gadd wrote: On Wed, Jul 17, 2013 at 5:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Dec 2012, Kevin Gadd wrote: Is it possible to expose the width/height of an ImageBitmap, or even expose all the rectangle coordinates? Exposing width/height would be nice for parity with Image and Canvas when writing functions that accept any drawable image source. By 'the other coordinates' I mean that if you constructed it from a subrectangle of another image (via the sx, sy, sw, sh parameters) it would be good to expose *all* those constructor arguments. This allows you to more easily maintain a cache of ImageBitmaps without additional bookkeeping data. Can you elaborate on this? Do you mean, e.g. making one ImageBitmap per sprite in a sprite sheet? If so, wouldn't you index by the name or ID of the sprite rather than the coordinates of the sprite in the sheet? On Tue, 18 Dec 2012, Kevin Gadd wrote: Sorry, upon reading over the ImageBitmap part of the spec again I'm confused: Why is constructing an ImageBitmap asynchronous? Because it might involve network I/O. I thought any decoding isn't supposed to happen until drawImage, so I don't really understand why this operation involves a callback and a delay. Making ImageBitmap creation async means that you *cannot* use this as a replacement for drawImage source rectangles unless you know all possible source rectangles in advance. This is not possible for many, many use cases (scrolling through a bitmap would be one trivial example). Yeah, it's not supposed to be a replacement for drawImage(). This is why I was confused then, since I was told on this list that ImageBitmap was a solution for the problem of drawing subrectangles of images via drawImage (since the current specified behavior makes it impossible to precisely draw a subrectangle). :( Oh. My apologies for any confusion caused here. The use case is being able to draw lots of different subrectangles of lots of different images in a single frame. Like, sprites? Wouldn't you know these ahead of time? You can, it's just significantly more complicated. It's not something you can easily expose in a user-consumable library wrapper either, since it literally alters the execution model for your entire rendering frame and introduces a pause for every group of images that need the use of temporary ImageBitmap instances. I'm compiling classic 2D games to JavaScript to run in the browser, so I literally call drawImage hundreds or thousands of times per frame, most of the calls having a unique source rectangle. I will have to potentially construct thousands of ImageBitmaps and wait for all those callbacks. A cache will reduce the number of constructions I have to do per frame, but then I have to somehow balance the risk of blowing through the entirety of the end user's memory (a very likely thing on mobile) or create a very aggressive, manually flushed cache that may not even have room for all the rectangles used in a given frame. Given that an ImageBitmap creation operation may not be instantaneous this really makes me worry that the performance consequences of creating an ImageBitmap will make it unusable for this scenario. If you have ImageBitmaps of subregions of a master image, I would imagine browsers could optimise that such that the ImageBitmaps don't take much memory at all. If they are sprites, you would know what they are ahead of time. If they're not, I'm not fully following what you mean. (I
[whatwg] ImageBitmap feature requests
On Thu, 18 Jul 2013, Justin Novosad wrote: On Thu, Jul 18, 2013 at 12:50 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Ashley Gullen wrote: Some developers are starting to design large scale games using our HTML5 game engine, and we're finding we're running in to memory management issues. Consider a device with 50mb of texture memory available. A game might contain 100mb of texture assets, but only use a maximum of 30mb of them at a time (e.g. if there are three levels each using 30mb of different assets, and a menu that uses 10mb of assets). This game ought to fit in memory at all times, but if a user agent is not smart about how image loading is handled, it could run out of memory. The Web API tries to use garbage collection for this; the idea being that you load the images you need when you need them, then discard then when you're done, and the memory gets reclaimed when possible. This is probably an area where most browsers could do a better job. Browsers should be able to handle the texture memory issues automatically without any new APIs, if they can't, then file bug reports. If garbage collection is not kicking-in at the right time, report it to the vendor. ImageBitmap should provide the same kind of pinning semantics as the suggested ctx.load/unload. This is good to know. If you are an author finding these problems, please do file bugs! However, one weakness of the current API is that upon construction of the ImageBitmap, the browser does not know whether the asset will be used with a GPU-accelerated rendering context or not. If this information were available, the asset could be pre-cached on the GPU when appropriate. Maybe something like ctx.prefetch(image) would be appropriate for warming up the caches. Is this a measurable performance problem currently? I'd hate to provide such an API, which could easily be misunderstood or misused, only to find that in practice things already work ok. On Fri, 19 Jul 2013, Ashley Gullen wrote: FWIW, imageBitmap.discard() wouldn't be unprecedented - WebGL allows you to explicitly release memory with deleteTexture() rather than letting the GC collect unused textures. What has implementation experience been with this API? Is it misused much? On Fri, 19 Jul 2013, Justin Novosad wrote: A related issue we have now is with canvas backing stores. It is common for web apps to create temporary canvases to do some offscreen rendering. When the temporary canvas goes out of scope, it continues to consume RAM or GPU memory until it is garbage collected. Occasionally this results in memory-leak-like symptoms. The usual workaround is to use a single persistent global canvas for offscreen work instead of temporary ones (yuck). This could be handled in a cleaner way if there were a .discard() method on canvases elements too. Would setting the canvas dimensions to zero have the same effect? We could have a method that just sets the dimensions to zero, if so, and if this is common enough to warrant a convenience method. On Fri, 19 Jul 2013, K. Gadd wrote: Some of my applications would definitely benefit from this as well. A port of one client's game managed to hit around 1GB of backing store/bitmap data combined when preloading all their image assets using img. Even though browsers then discard the bitmap data, it made it difficult to get things running without killing a tab due to hitting a memory limit temporarily. (The assets were not all in use at once, so the actual usage while playing is fine). Having explicit control over whether bitmaps are resident in memory would be great for this use case since I can preload the actual file over the network, then do the actual async forced decode by creating an ImageBitmap from a Blob, and discard it when the pixel data is no longer needed (the game already has this information since it uses the C# IDisposable pattern, where resources are disposed after use) Well, browsers should be more aggressive about garbage collecting if the lack of having garbage collected is causing performance issues due to lack of RAM, no? Have you filed any bugs on browsers for this? Justin's comments above suggests we should maybe start with that. On Tue, 13 Aug 2013, Kenneth Russell wrote: We could have a constructor for ImageData objects, sure. That would be relatively easy to add, if it's really needed. I don't understand why it's hard to keep track of ImageData objects, though. Can you elaborate? I have in mind new APIs for typed arrays which allow sharding of typed arrays to workers and re-assembly of the component pieces when the work is complete. This would involve multiple manipulations of the ArrayBuffer and its views. It would be most convenient if the result could be wrapped in an ImageData if it's destined to be drawn to a Canvas. Otherwise it's likely
Re: [whatwg] WebGL and ImageBitmaps
On Fri, 9 May 2014, Ian Hickson wrote: On Thu, 18 Jul 2013, Justin Novosad wrote: To help us iterate further, I've attempted to capture the essence of this thread on the whatwg wiki, using the problem solving template. I tried to capture the main ideas that we seem to agree on so far and I started to think about how to handle special cases. http://wiki.whatwg.org/wiki/ImageBitmap_Options Are the strongly desired options in the above wiki page still the options we should be adding? On the assumption that they are, I filed some bugs to cover this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25642 createImageBitmap() options: image data orientation https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643 createImageBitmap() options: color space handling https://www.w3.org/Bugs/Public/show_bug.cgi?id=25644 createImageBitmap() options: alpha channel handling As usual with such bugs, if there is interest amongst browser vendors in implementing any of these, please comment on the bug. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Mon, 5 May 2014, Kenneth Russell wrote: It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. Progress can be made imminently. Just tell me what you need. There's no reason this has to take a long time. The only reason it isn't in the spec already is that it hasn't been requested -- as far as I'm aware, until the past week, the last person who mentioned it on the list was me, several years ago. If multiple vendors are interested in a more elaborate solution that doesn't expose more fingerprinting bits, we can do that right away. What would be most helpful to do that is detailed descriptions of use cases, common pitfalls, experience with existing systems like Apple's GCD, strawman API proposals, and criticisms thereof. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Mon, 5 May 2014, Eli Grey wrote: GCD exposes core count in that you can make your jobs keep track of the current time and then count how many threads are running at the same time. A GCD-style API will enable me to replace all of Core Estimator's estimation and statistical code with a very simple counter and time tracker, while yielding fully accurate core counts. I honestly cannot think of a system that doesn't make it possible to derive core count even easier than I currently can. You are assuming that the system is not under load. This is a false assumption. (Your current core estimator makes the same mistake, as I and others have pointer out several times.) You're also assuming there's no potentially-variable per-origin thread limit, etc, which is also a false assumption (q.v. Gecko's implementation of Workers today, as bz pointed out earlier). Indeed, on a high-core machine as we should expect to start seeing widely in the coming years, it might make sense for the browser to randomly limit the number of cores on a per-origin/session basis, specifically to mitigate fingerprinting. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. Why are the concerns raised at that time no longer valid? As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting I'm not responsible for what individual browser vendors do. Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 I'm not responsible for what editors of other standards do. The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Sure we can. You don't need to know how many cores a system has, you need to know how you can make optimal use of the resources of the system without affecting other tasks that the user is running. There are plenty of ways we can address this use case that don't expose the number of cores as a reliable metric. On Sun, 4 May 2014, Rik Cabanier wrote: As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Right. You have to install the application. At that point, game over. The point is that on the Web there's no installation step. This is a feature. It's one of the Web's most critically powerful assets. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) Sure. Once you've agreed to just let the application reside on your system, then you can fingerprint the user with impunity. The Web is better than that, or at least, we should make it better. Are you saying it's better that people use an estimator poly-fill? No, I'm saying we should provide an API to address the underlying use case -- making optimal use of CPU resources -- without increasing the fingerprinting risk. On Sun, 4 May 2014, Eli Grey wrote: On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? The explicit permission is you can run on this system. On iOS, Android, MacOS, Linux, Windows, and pretty much every other platform, before you can run code on the system, the user or administrator has to explicitly install your code. On the Web, all it takes is visiting a URL. There's no installation step, there's no need for the user to click through a dialog saying running native code is highly risky. Because the Web has a dramatically lower bar for running code, we have to have a dramatically higher bar for protecting the user. Neither iOS or Android requires any specific permissions for this information. You can create an Android application that requests absolutely no permissions that can read the core count and display it to the user. No, you can't. You need one explicit permission: the permission to run in the first place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hidden attribute useless with display: flex?
On Thu, 1 May 2014, David Bruant wrote:
Le 30/04/2014 23:32, Ian Hickson a écrit :
What I'm trying to do is just that an element have display:flex
and to hide it with the hidden attribute when I don't need the
element to be shown. I guess my only option is changing
style.display?
Just add [hidden] { display: none } to your style sheet.
Hmm... interesting. And that works because my stylesheet is the author
stylesheet which takes precedence over the UA stylesheet.
Is there a scenario where CSS specificity leads to this rule being
ignored?
Yeah, as usual specificity can rock the boat. :-)
div.ui { display: flex; }
...would override it (since 0,0,1,1 0,0,1,0). But if that's an issue,
you can move this to the !important level:
[hidden] { display: none ! important; }
If the answer is no, I'm sold. It's not any worse than *{box-sizing:
border-box} which I do all the time.
Yeah, it's exactly like that. Or * { font: inherit; }, which I do all the
time, but which you then have to fix for headings and strong and so on.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframes, more sandbox
On Thu, 6 Feb 2014, Chris Coyier wrote: I'm hoping for more a little bit more control over iframes. We have iframe sandbox which is pretty fantastic right now. I'd like to see some possibilities in both directions (more and less strict). More strict: - Disallow modal dialogs (e.g. alert, confirm) but otherwise allowing scripts via allow-scripts We could do this by having an allow-limited-scripts instead of allow-scripts, which doesn't allow things like alert() and confirm(). We'd need a precise list of what should be allwoed and what should not. Or, we could just kill those APIs in sandboxed iframes. How many sandboxed iframes rely on alert() in a non-annoying fashion? - Also dialogs like when a page or resource is .htpasswd protected I'm actually rather surprised that browsers still show these for iframed content. (I checked, and Firefox, Safari, and Chrome indeed do.) Maybe we should see if we could get that changed to a non-modal solution before providing a markup way to prevent it altogether. - Do not make sound, period. Autoplay is already disabled in sandbox, but can be circumvented (e.g. by creating new audio element that autoplays, apis that create iframes (soundcloud, vimeo) that then play). You can circumvent it via script (calling .play()). That's all, though. We could block .play() and friends via allow-limited-scripts, if that's the issue. Or we could automute all media elements and make the unmuting APIs blocked if you have allow-limited-scripts set. It's presumably ok if the user is the one that plays the audio in the iframe? Less strict: - Allow some safe version of target=_blank links Isn't that what allow-popups does? On Mon, 10 Feb 2014, Chris Coyier wrote: I'm not sure if this is a complete list, but: alert, alert1, confirm, prompt, the one from window.onbeforeunload, and the one from .htpasswd What is alert1? I can imagine further tightening like stopping .play() from working, but then not doing anything to stop the web audio api for instance. So rather than stop each one specifically, just neuter the whole system. Web Audio would be something we could prevent if allow-limited-scripts was enabled. Or, we could mute the audio in the iframe if that was set, with a non-modal infobar allowing the user to unmute it. I'm skeptical about wanting to prevent audio when an iframe contains a video that the user started or unmuted though. - Cannot contain another iframe Why? Which problem does this solve? The thinking here is that new iframes have a new window object. So in the past I've dealt with annoyingness-prevention by overriding functions like alert and confirm. But you can get around that by creating a new iframe (of which there are rather infinite ways to do that) which gives you that fresh window object in which to do an alert, which then pops up on the very top parent page. If you can access the frame's Window object, the frame can access yours. So that seems like a very dangerous game. Unless you have allow-same-origin, you're not going to be able to get to the iframe contents anyway. And unless you have allow-scripts, they're not going to be running any scripts. And if you have both, you've lost. The other concern is the audio/video thing, in which an injected (say, Vimeo) iframe can autoplay. If we prevent audio, a nested iframe can't play audio. Sandbox applies to all subiframes. Stretch goal: setting some limit on memory usage by an iframe. That's somewhat up to the UA. In my mind, perhaps the #1 reason to sandbox an iframe is preventing XSS. There are so many ways to change the window location, it's awesome to have a way to prevent them all. e.g. window[l+ocation] = http://google.com; + document.cookie (sigh). However, the goal (for me) isn't so much the preventing of location changing but the danger of XSS. So perhaps it would be possible to 1) still disallow all top location changing 2) allow target=_blank links that are sanitized (somehow guaranteed to not be passing sensitive data). Maybe not possible. If you're allowing scripting, there's no way to tell if the data is sensitive or not. Fundamentally, a page could encrypt the data in a way that makes it look like noise. But I don't really understand what XSS you're concerned about. If you're worried about the page accessing the local origin's content, then sandboxing solves that (unless you set allow-same-origin). If you're concerned about the page running script, then sandboxing solves that (unless you set allow-scripts). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on seamless iframe attribute
On Mon, 3 Feb 2014, Ben Vinegar wrote: But while we’re not interested in the style component of the seamless attribute, we – and probably all developers that hack on iframes – are interested in the resizing behaviour it introduces. Right now we deploy fairly complex code, both inside the iframed document, and on the parent document, to resize the iframe element when the iframed content changes size. Every iframed application with dynamically-sized content does the same. Thanks for descrbing this use case. It has come up before, as it happens. Combined with the desire for other aspects of seamless= to apply to cross-origin iframes, the current proposal is to have headers that enable these features on the embedee site, with CSP being used to decide which origins are allowed to use the feature at all. You can see more about this at these links: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 The current blocker is getting implementor interest; right now, most implementors haven't finished (or in some cases even started) supporting seamless= even for same-origin iframes, so we don't want to start adding more features yet lest we get too far ahead of the browsers. To me, it’s crazy that it’s 2013 and there’s still no native way to have the browser automatically resize an iframe. And yet we have seamless. But it not only resizes: it adds all this other bundled behaviour, and strictly serves a fringe use case where somebody is distributing iframes on the same origin. The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hidden attribute useless with display: flex?
On Wed, 30 Apr 2014, David Bruant wrote:
Le 29/04/2014 23:32, David Bruant a écrit :
// CSS:
div {
display: flex;
}
// HTML:
div hidden/div
Per spec, the div should be shown right? I imagine there is no way
back on that?
Right. You want:
div[hidden] { display: block }
...in your style sheet. It's the equivalent of:
strong { font: 1em sans-serif; }
...removing the bold, or:
td.foo { display: none; }
...making all the cells after td class=foo end up in the wrong column.
Does it mean hidden only works when the default (UA stylesheet)
display value is kept? Does it mean hidden is completely useless when
trying to combine it with display:flex?
No, it just means you have to be careful with your CSS.
Personally I often use this rule:
[hidden] { display: block; opacity: 0; }
...combined with CSS transitions to animate elements that are being hidden
or shown. This is one example of why it's important that author CSS be
able to override the default CSS.
What I'm trying to do is just that an element have display:flex and to
hide it with the hidden attribute when I don't need the element to be
shown. I guess my only option is changing style.display?
Just add [hidden] { display: none } to your style sheet.
Constructive proposal:
* a special value for the hidden attribute that forces the element to be
hidden regardless of what the CSS or style attribute says for the display
value.
Maybe `hidden=force`?
Hidden how? 'visibility'? 'display'? 'opacity'? Why? What if you later
want to style it differently?
On Wed, 30 Apr 2014, Anne van Kesteren wrote:
We could change the specification to use display-box instead. That might
work.
Would that break sites that are intentionally replacing the styling for
hidden= from 'display:none' to 'opacity:0' ?
On Wed, 30 Apr 2014, Glenn Maynard wrote:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037905.html
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0143.html
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Any plan for a TIMEOUT section on appcache manifests ?
On Tue, 18 Dec 2012, Nicolas Froidure wrote: I'm using the appcache since it's adoption on major browsers and i think it lacks of a section to specify fallbacks with a specific timeout in order to avoid slow networks to damage user experience. To me this is the main issue still remaining in order to have the same experience than installed apps. It could take the form of a section like this (with a 2 seconds timeout): TIMEOUT 2: onlineres.html fallbackres.html Or maybe be done with the connection types : BANDWIDTH EDGE: onlineres.html fallbackres.html ... Is it planned to have some similar mechanism ? Isn't this something browsers should just implement themselves? It's not clear to me how an author is supposed to know what timeout to give. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
This discussion focused around the various behaviours that browsers have
around the rendering of br.
On Thu, 23 Jan 2014, Boris Zbarsky wrote:
What Gecko does with br is basically to treat it like a special box
type that has special sizing/painting/linebreak behavior. But we do
still allow that box to be positioned/floated, just like an img...
On Tue, 28 Jan 2014, Elliott Sprehn wrote:
Blink treats br (conceptually) like a subclass of Text, there's
nothing to style because it's just a run of text with a forced break.
On Wed, 29 Jan 2014, Tab Atkins Jr. wrote:
We talked this over in the CSSWG meeting, and came up with a proposal
for non-magical styling that is still very close to current behavior in
all browsers:
br {
display-box: contents;
content: \A;
white-space: pre;
}
I've filed a bug to track this. It would be useful if browser vendors
could indicate whether they think Tab's proposal is satisfactory (in
particular, is 'display-box' something that browsers will implement?
Apparently Gecko is doing it, anyone else?).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] canvas feedback
On Tue, 8 Apr 2014, Rik Cabanier wrote: On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson i...@hixie.ch wrote: So this is not how most implementations currently have it defined. I'm unsure what you mean. Browser implementations? If so, they definitely do store the path in user coordinates. The spec currently says otherwise [1] though. I'm not sure what you're referring to here. All graphics backends for canvas that I can inspect, don't apply the CTM to the current path when you call a painting operator. Instead, the path is passed as segments in the current CTM and the graphics library will apply the transform to the segments. Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. As far as I can tell, these are block-box indistinguishable statements. Can you show a test case that demonstrates how the spec doesn't match browsers? [use case: two paths mapping to the same region] Just use two different IDs with two different addHitRegion() calls. That's a lot less complicated than having a whole new API. That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: # If there is a previous region with this control, remove it from the # scratch bitmap's hit region list; then, if it had a parent region, # decrement that hit region's child count by one. Interesting. You mean like a case where you had a button that got split into multiple segments animated separately that then joined together, but where you want to be able to click on any part of that split-up button? Hmm. There's several ways we could support that. The simple way would be to allow multiple regions to refer to a control. The more subtle way would be to allow the control logic to defer to the parent region, but that's probably a bad idea (where would you put the parent region?). So I guess the question is: is it more useful to be able to refer to the same control from multiple regions, or is it more useful for the previous region to be automatically discarded when you add a new one? It's probably more useful to have multiple regions. You can always do the discarding using IDs. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. Why? I think that makes a lot of sense. There are multiple regions, why not have multiple hit regions? This becomes especially true when the multiple regions might be differently overlapped by other regions, or where different parts of the canvas are renderings from different angles of the same underlying scene. It would be silly for things to be easier to do with two canvases than one, in that kind of case, no? I've changed the spec to not discard regions based on the control. On Fri, 6 Dec 2013, Jürg Lehni wrote: Instead of using getCurrentPath and setCurrentPath methods as a solution, this could perhaps be solved by returning the internal path instead of a copy, but with a flag that would prevent further alterations on it. The setter of the currentPath accessor / data member could then make the copy instead when a new path is to be set. This would also make sense from a a caching point of view, where storing the currentPath for caching might not actually mean that it will be used again in the future (e.g. because the path's geometry changes completely on each frame of an animation), so copying only when setting would postpone the actual work of having to make the copy, and would help memory consummation and performance. I don't really understand the use case here. Jurg was just talking about an optimization (so you don't have to make an internal copy) Sure, but that doesn't answer the question of what the use case is. From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Sure, but the brief transitional cost of moving from canvas current default paths to Path2D objects is minor on the long run, and not worth the added complexity cost paid over the lifetime of the Web for the feature. So for something like this, we need a stronger use case than it makes transitioning to Path2D slightly easier. On Wed, 12 Mar 2014, Rik Cabanier wrote: You can do unions and so forth with just paths, no need
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, 16 Apr 2014, Boris Zbarsky wrote: Right now canvas drawImage ignores EXIF orientation metadata. Could we add a version that doesn't do that? Especially with CSS growing things like the image-orientation property, it would be good to support drawing the image in its correct orientation. On Wed, 16 Apr 2014, Justin Novosad wrote: But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. On Wed, 16 Apr 2014, Anne van Kesteren wrote: Why is image-orientation in CSS for img? For background-image that makes sense, but if you are actually affecting the semantics of the image that is displayed, it seems like it should be in HTML or a hint in the image format. On Wed, 16 Apr 2014, Justin Novosad wrote: Yes, that makes a lot of sense IMHO. I just posted feedback to www-style The feedback seemed positive: http://lists.w3.org/Archives/Public/www-style/2014Apr/thread.html#msg179 This proposal seems pretty reasonable. I'm tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 On Wed, 16 Apr 2014, Justin Novosad wrote: Another use case to think about is: XHR-Blob-ImageBitmap-Canvas(2D or WebGL) With that data flow, there is no opportunity to use a CSS property to tweak image orientation. There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 If other vendors want to do this, please comment on the bug (or here). Here is a summary of related bugs: Regarding EXIF: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23510 Allow EXIF data to be passed to toBlob() This is pending implementation interest from browsers outside Mozilla, and someone coming up with a way to map EXIF to JSON in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23511 Expose EXIF data of images in img elements This is pending implementation interest and would also benefit from a way to map EXIF to an API in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 Have createImageBitmap() take options, e.g. to honour EXIF orientation This is pending implementation interest outside Chrome. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Have an attribute that honours EXIF orientation This seems to have implementation interest from everyone, and I'll hopefully be adding it soon. Need a good name; if you have a suggestion, add it to the bug. Regarding drawImage(): https://www.w3.org/Bugs/Public/show_bug.cgi?id=17427 drawImage() should accept SVGImageElement (svg:image) This is blocked on the SVG spec being updated to define image loading in a suitable level of detail. It could also do with interest from browser vendors other than Mozilla. Regarding ImageBitmap: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21346 Have ImageBitmap expose height and width attributes This is pending implementation interest outside Chrome. Regarding img: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 Feature to make img elements not load their images until needed This is something I plan to deal with at the same time as script preloading, object preloading, et al. Right now I'm waiting to see if public-web-perf (the W3C WG) is going to move on this topic. No ETA. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24711 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24958 Refactor the image loading model; When exactly should update the image data run? The current img loading model doesn't match browsers well enough and I need to work on that. If you have thoughts on how image loading should work, please comment on bug 24711 soon. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] BroadcastChannel should support structured clones
On Thu, 17 Apr 2014, Jonas Sicking wrote: It would be very useful to be able to send structured data, including Blobs, through the BroadcastChannel API. This is something we've seen any time we've done storage or message passing, that one of the first thing authors ask for is to not have to do JSON serialization/parsing manually. The ability to pass ArrayBuffers and Blobs is somewhat less commonly asked for, likely because binary data is less often used, but seems important nonetheless. We can't allow transferring of objects, since you can't transfer something to all listeners of a broadcasting API. But plain structured clones should be no problem to support conceptually (though more work to implement of course). We've started looking at doing structured clone support for Firefox and likely won't ship until we have that implemented. This would make a lot of sense. I think when I was first speccing this I wanted to avoid transferring and forgot that you could clone without transferring! I see that you filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25415 ...so I'll track it there. For implementation purposes you can assume that I'm going to make this change. On Thu, 17 Apr 2014, Jonas Sicking wrote: Another thing that seems like an oversight in the spec is that the spec currently says that BroadcastChannel should be exposed in Window context. We should also expose it in Worker contexts. I had filed a bug to track this earlier: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24414 If you want to implement this in workers please do go ahead. I was just waiting for people to implement it at all before doing the minor work of updating the spec for workers (mostly, as noted in the bug, changing the responsible document stuff to check for worker event loops instead when in a worker, and excluding suspended workers). I've moved the bug back onto my radar. For people following on at home, there's also this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25414 ...relating to the order of events in a broadcast channel, and this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25413 ...wherein I'm about to change how channel names are exposed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, 20 Feb 2014, Ashley Gullen wrote: We're building a browser-based P2P multiplayer engine on top of WebRTC DataChannels. You can try out our work-in-progress here: http://www.scirra.com/labs/multiplayer/test1/ The first player in to a room is assigned the host, and all other subsequently joining peers connect to the host with WebRTC DataChannels and start exchanging game data. Like all responsible HTML5 games, it runs based on a requestAnimationFrame loop. requestAnimationFrame() is for animations, not for logic. For logic, your better bet is to use a worker or, at worst, setInterval(). To prevent multiplayer games commonly hanging, perhaps there could be a new API to request that a page can keep running at full capacity even in the background, such as window.requestBackgroundProcessing(). Workers are the mechanism for running code in the background. I would strongly recommend not using a peer server architecture, though. Doing this requires trusting the client, which is highly dubious. A hostile player could just inject arbitrary code into your logic, and subtly cheat without being detected. It also means that handling the host crashing or closing their laptop or going into a tunnel is different than the same for another player, which is a sucky experience for everyone. On Thu, 20 Feb 2014, Glenn Maynard wrote: On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier wrote: Is WebRTC available in a worker? I don't know, but if not, fixing that is probably closer to the right direction than letting people run fast timers in minimized UI threads. Yeah. If WebRTC isn't being exposed to workers, I recommend bringing that up with the editor of the WebRTC spec. On Thu, 20 Feb 2014, Ashley Gullen wrote: There's a lot of worker features that aren't widely supported yet, like rendering to canvas with WebGL and 2D, Web Audio support, inputs, various APIs like speech and fullscreen, so I don't think that's practical right now. Presumably your server logic doesn't need to be fullscreen... On Thu, 20 Feb 2014, Ashley Gullen wrote: Since it's a peer-to-peer engine, the user acting as the server is also a participant in the game. This means the server is also running the full game experience with rendering and audio. That part of the logic should be in the tab. Then the tab just acts as a client to the server in the worker, in the same way that the other clients for the other players do. The game logic is tied to rAF, since we intend to step the world once per screen draw, including for the player acting as a server. Different players are going to have different frame rates, so it doesn't make sense to make one player's frame rate more important than another's. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
