Re: [whatwg] Feedback on Meta referrer
On Thu, 05 Jan 2012 18:37:05 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/2/12 1:55 AM, Simon Pieters wrote: What about: head script src=foo.js/script meta name=referrer content=never link rel=stylesheet href=a.css /head ...and the browser speculatively fetches the stylesheet before the meta element is in the DOM? Should the speculative parser have knowledge of meta name=referrer? I would say it should handle this just like it handles base tags, whether that's through keeping track of it or through the speculation failing. OK, so the speculative parser needs to scan for the feature. My thinking was that the speculative parser currently doesn't need to look at meta, but it does look at base, and usually there's zero or one base but can be lots of metas, so it could be slightly cheaper to put this on base compared to meta. Maybe the difference is negligible, though. Yeah. Is there some precedent we should look to here? Perhaps the base element? Perhaps this should even be an attribute on base -- base referrer=... Note that when you have multiple base tags only the _first_ takes effect, Only for the same attribute -- if you have one base href and one base target they both get applied. (Which still isn't the proposed behavior for meta referrer, I know.) which is not the proposed behavior for meta referrer... -- Simon Pieters Opera Software
Re: [whatwg] Spec with Implementation Details Highlighted?
On Sat, 7 Jan 2012, Smylers wrote: If it's something you'd find useful even in its incomplete state, I can add an alternative style sheet Yes, please. Roger. I've added an alternative style sheet set that has a rule for .impl sections for you. HTH. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Bug 12287] Restrict sequenceT to operation argument types and return types
On Mon, 23 May 2011, and...@ado.is-a-geek.net wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12287:
sequenceT has undesirable behaviour in JS when used as an attribute
value, so we should consider preventing its use there.
HTML5 Section 10:
typedef sequenceMessagePort MessagePortArray;
interface MessageEvent : Event {
readonly attribute any data;
readonly attribute DOMString origin;
readonly attribute DOMString lastEventId;
readonly attribute WindowProxy source;
readonly attribute MessagePortArray ports;
void initMessageEvent(...);
};
The WebIDL specification has been changed so the MessageEvent interface
in HTML5 is no longer valid. This only appears to have been implemented
by Opera at the moment, and it returns the same ECMAScript Array every
time it is called. I would guess this can still be changed given that
it is not widely implemented.
Can MessagePortArray be changed to be some kind of collection like many
of the other places in DOM when we want a list of children? This would
probably be easiest for me, but perhaps there is a better way.
I believe this has since been fixed; the spec now uses MessagePort[] as
the type for MessageEvent.ports.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Tue, 5 Jul 2011, Robert O'Callahan wrote: On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Fri, May 13, 2011 at 5:53 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 May 2011, Robert O'Callahan wrote: Can you put a note in the spec that we're thinking of changing this behavior, so developers are less likely to start depending on it, and we've got some cover in case it breaks some esoteric stuff that doesn't matter for compat? Done. Thanks. I made this change on mozilla-central so it should appear in Firefox 7 about 18 weeks from now --- unless we detect that it breaks the Web. It breaks the Web, so we're backing it out. It turns out that a lot of canvas apps set up a shadow color and blur, do some drawing, then disable the shadow by setting the blur to zero. With the proposed change, those apps often render incorrectly, and worse, they often render more slowly. Should we still make shadows only work in source-over mode, or should we leave the spec as is in this area? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Tue, 31 May 2011, Henri Sivonen wrote: Recently, there was discussion about changing media element state in the same task that fires the event about the state change so that scripts that probe the state can make non-racy conclusions about whether a certain event has fired already. Currently, there seems to be no correct non-racy way to write code that probes a document to determine if DOMContentLoaded or load has fired and runs code immediately if the event of interest has fired or adds a listener to wait for the event if the event hasn't fired. Are there compat or other reasons why we couldn't or shouldn't make it so that the same task that fires DOMContentLoaded changes the readyState to interactive and the same task that fires load changes readyState to complete? Fixed for 'load'. I don't see a good way to fix this for 'DOMContentLoaded', unfortunately. Note that 'readystatechange' events do fire synchronously with 'readyState' changes so you can always just use that instead of 'DOMContentLoaded' and 'load'. I haven't changed 'pageshow', so you could still get code running between 'load' and 'pageshow'. Let me know if you think we should merge those into one task as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Tue, Jan 10, 2012 at 12:52 PM, Ian Hickson i...@hixie.ch wrote: Should we still make shadows only work in source-over mode, or should we leave the spec as is in this area? It's probably not worth changing the spec at this time. I think it would be a bit simpler, and if we run into problems with shadows and non-over operators (author confusion, implementation issues) then I think we could still do it. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
[whatwg] should we add beforeload/afterload events to the web platform?
WebKit supports a 'beforeload' event [1] which is supported in shipping Safari and Chrome[2] and apparently has (enabled) the real-world use-cases of: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension[2] 2. Clientside transformations, e.g. Mobify[3] As might be expected, there is at least one use-case for a complementary 'afterload' event: 1. Downloadable fonts - people who want to use custom fonts for drawing in the canvas element need to know when a font has loaded. 'afterload' seems like a good way to know that, since it happens as a side effect of actually using it and fonts don't have an explicit load API like images do.[4] Safari and Chrome have already shipped 'beforeload', and Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4] Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? Rather than attempt to provide a specific detailed design at this point, I'd prefer to ask for the list's consideration/discussion, and leave detailed specification of the two events to the editor. Thanks, Tantek [1] http://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html [2] http://google-chrome-browser.com/tags/beforeload [3] http://mobify.com/static/talks/client-side-transformations.html#27 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=715695#c9 -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/10/12 12:48 AM, Tantek Çelik wrote: Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4] It's more like one person in a Mozilla bug has suggested that it be implemented, while others, myself included, are a bit skeptical. The devil, of course, is in the details; if this event is specified very carefully it might simply slow down pageload a bit, more so as browsers introduce more parallelism because background threads or processes that might be able to perform the load will have to block on the main page JS thread to handle the event first. If done carelessly (e.g. the event target is the node the load is associated with), it'll be a pretty large slowdown. For example, that approach precludes the sort of speculative parsers UAs use nowadays to deal with having to block parsing on script tags. Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? Outside of extensions, what are the use cases? Can they usefully labor under restrictions like knowing the URI to be loaded but not the context it's being loaded in? AdBlock apparently can in at least some cases, yes? I'd like to understand the client-side transformation use-case better, in particular. What is it really trying to do? -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/10/12 1:02 AM, Boris Zbarsky wrote: I'd like to understand the client-side transformation use-case better, in particular. What is it really trying to do? OK, I got more context on this. The goal of the client-side transformation case is effectively do something like what one can do with XSLT in XML. Specifically: 1) Don't actually render the HTML coming down the pipe. This includes not doing any loads from it, but also includes not actually doing layout, not running scripts in the page, etc. 2) Bind some sort of transformation to it (in this case a script that runs on the DOM or on the original source, depending). 3) Render the result of that transformation. mobify uses beforeload for a poor-man's approximation to #1: it can block loads, but not prevent execution of inline scripts or prevent layout (short of adding display:none styles to the page itself). Then it does various other hackery to do #2 and #3. I agree that this is a good use case to solve, but beforeload doesn't really solve it. We should provide a better solution. For the rest, I just checked and WebKit does set the event target to the node triggering the load, at least for script nodes. I can nearly guarantee that we would NOT be willing to do that in Gecko even if we were convinced that the 'beforeload' event is a good idea in the first place. The 'afterload' event doesn't have the same sort of problems, of course; it's no different from existing 'load' events in cases when it's fired on an element. Whether it provides a good solution for other cases, I haven't had a chance to think through yet. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 10, 2012 at 7:48 AM, Tantek Çelik tan...@cs.stanford.edu wrote: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension[2] Extension use cases don't require an API exposed to Web content, though. Furthermore, IE9 has a built content blocking rule engine and Firefox has a de facto dominant rule engine for year even though it has been shipped separately (AdBlock Plus). Maybe instead of exposing arbitrary programmability for content blocking, other browsers should follow IE9 and offer a built-in rule engine for content blocking instead of letting extensions run arbitrary JS to inspect every load. 2. Clientside transformations, e.g. Mobify[3] There's already an easier cross-browser way to deactivate an HTML page and use its source as input to a program: document.write(plaintext style='display:none;'); (This gives you source to work with instead of a DOM, but you can explicitly parse the source to a DOM.) Anyway, I'd rather see mobile adaptations be based on CSS instead of everyone shipping a bunch of JS to the client munge the page in ways that foil all optimizations that browsers do for regular page loads. As might be expected, there is at least one use-case for a complementary 'afterload' event: 1. Downloadable fonts - people who want to use custom fonts for drawing in the canvas element need to know when a font has loaded. 'afterload' seems like a good way to know that, since it happens as a side effect of actually using it and fonts don't have an explicit load API like images do.[4] It seems like fonts should have an API for listening when they become available, yes. Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? I'm worried about the interaction with speculative loading. Right now, Gecko is more aggressive than WebKit about speculative loading. I don't want to make Gecko less aggressive about speculative loading in order to fire beforeload exactly at the points where WebKit fires them. I'm even worried about exposing resource load decisions to the main thread at all. Right now in Gecko, the HTML parser sees the data on a non-main thread. Networking runs on another non-main thread. Even though right now speculative loads travel from the parser thread to networking library via the main thread, it would be unfortunate to constrain the design so that future versions of Gecko couldn't communicate speculative loads directly from the parser thread to the networking thread without waiting on the main-thread event loop in between. (In this kind of design, a built-in content blocking rule engine would be nicer than letting extensions be involved in non-main threads.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] di? Please?
As I understand it, the main reason for rejecting di was that it solves a problem that is allegedly CSS's job, but as an author who uses dls quite extensively, adding a grouping element would really make my life a lot easier. Yes, my most common problem with dls is styling them, but it's hardly CSS's fault. What kind of styling am I attempting to do? Mostly, to arrange them in columns. Why not use table? Because the data is at most two-dimensional (i.e., serial, not tabular) and consists of definitions rather than arbitrary data. Why would I want to to arrange the data in this way? The same reason I would want to arrange most things in columns: to use vertical space efficiently when I have it. I've tried, and as far as I can tell, this can't be achieved with floats. Even if it can, it's prohibitively unintuitive enough to someone with considerable CSS experience. The only way I have done it is with absolute positioning, which of course takes you out of normal flow and into fixed coordinate positioning; hardly tenable considering the flexibility requirements of fluid, and now responsive designs. Even recent additions like CSS3 columns are a blunt instrument in this regard, which often result in widows/orphans unless height is manipulated manually to force everything into place (a nonstarter for separation of concerns). Yet, I can achieve this easily with uls and with tables, with headings and paragraphs inside of various containers; I can do it with essentially every other data structure but dl, and that's no coincidence: dls are notoriously hard to style specifically because they're loosely-structured; they lack the grouping semantics which are paradoxically abundant in other content models. Because of this, I have in the past resorted to either: A.) choosing a less-semantically-accurate, but more flexible structure; or B.) splitting the dl into two dls. I tend to opt for B. simply because I want to retain the dl semantics, but it's still less-than-desirable because the motivation for doing so is purely presentational. Sibling dls are as silly as sibling ul/ols: if there's no reason to have other content between them (such as an explanation about what the second list represents), there's no reason not to enumerate them all in the same list. Yet, it's the only practical way to achieve this effect. I have a feeling most authors would opt for A., however, which diminishes the utility of dl by making it even more rarely used. The way I see it, di has more or less identical use cases to section. Despite the fact that we have an outlining algorithm that will automatically determine the structure of your content without using section at all, authors are still free to use grouping mechanism to make sectioning explicit, which is necessary to avoid ambiguity. Take this for example: section h3foo/h3 pbar/p /section section h3baz/h3 pqux/p /section pquux/p …where the absence of sections would result in two titled sections, rather than the desired: three sections, two of which are titled and one of which is untitled. This is in no way different from the following: di dtfoo/dt ddbar/dd /di di dtbaz/dt ddqux/dd /di ddquux/dd …where the absence of dis would result in two named values, rather than the desired: three values, two of which are named and one of which is unnamed. Simply put: just because the parsing algorithm is well-defined and we can imply association sans-container, that doesn't mean authors (like myself) won't want finer-grained control over grouping. Is there a compelling reason why, given the current dl content model, it is possible to create a list of: nothing but unnamed values, nothing but valueless names, an unnamed value followed by a named value, a named value followed by a valueless name, but NOT a named value followed by an unnamed value—what makes that last scenario any less useful than all of the others? If anything it's probably the *most* useful, since valueless names and nameless values can already be represented by ul/ol.
Re: [whatwg] di? Please?
Sounds like what you want is flex box. Have you looked at that yet? Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com On Jan 9, 2012, at 11:32 PM, Hugh Guiney hugh.gui...@gmail.com wrote: As I understand it, the main reason for rejecting di was that it solves a problem that is allegedly CSS's job, but as an author who uses dls quite extensively, adding a grouping element would really make my life a lot easier. Yes, my most common problem with dls is styling them, but it's hardly CSS's fault. What kind of styling am I attempting to do? Mostly, to arrange them in columns. Why not use table? Because the data is at most two-dimensional (i.e., serial, not tabular) and consists of definitions rather than arbitrary data. Why would I want to to arrange the data in this way? The same reason I would want to arrange most things in columns: to use vertical space efficiently when I have it. I've tried, and as far as I can tell, this can't be achieved with floats. Even if it can, it's prohibitively unintuitive enough to someone with considerable CSS experience. The only way I have done it is with absolute positioning, which of course takes you out of normal flow and into fixed coordinate positioning; hardly tenable considering the flexibility requirements of fluid, and now responsive designs. Even recent additions like CSS3 columns are a blunt instrument in this regard, which often result in widows/orphans unless height is manipulated manually to force everything into place (a nonstarter for separation of concerns). Yet, I can achieve this easily with uls and with tables, with headings and paragraphs inside of various containers; I can do it with essentially every other data structure but dl, and that's no coincidence: dls are notoriously hard to style specifically because they're loosely-structured; they lack the grouping semantics which are paradoxically abundant in other content models. Because of this, I have in the past resorted to either: A.) choosing a less-semantically-accurate, but more flexible structure; or B.) splitting the dl into two dls. I tend to opt for B. simply because I want to retain the dl semantics, but it's still less-than-desirable because the motivation for doing so is purely presentational. Sibling dls are as silly as sibling ul/ols: if there's no reason to have other content between them (such as an explanation about what the second list represents), there's no reason not to enumerate them all in the same list. Yet, it's the only practical way to achieve this effect. I have a feeling most authors would opt for A., however, which diminishes the utility of dl by making it even more rarely used. The way I see it, di has more or less identical use cases to section. Despite the fact that we have an outlining algorithm that will automatically determine the structure of your content without using section at all, authors are still free to use grouping mechanism to make sectioning explicit, which is necessary to avoid ambiguity. Take this for example: section h3foo/h3 pbar/p /section section h3baz/h3 pqux/p /section pquux/p …where the absence of sections would result in two titled sections, rather than the desired: three sections, two of which are titled and one of which is untitled. This is in no way different from the following: di dtfoo/dt ddbar/dd /di di dtbaz/dt ddqux/dd /di ddquux/dd …where the absence of dis would result in two named values, rather than the desired: three values, two of which are named and one of which is unnamed. Simply put: just because the parsing algorithm is well-defined and we can imply association sans-container, that doesn't mean authors (like myself) won't want finer-grained control over grouping. Is there a compelling reason why, given the current dl content model, it is possible to create a list of: nothing but unnamed values, nothing but valueless names, an unnamed value followed by a named value, a named value followed by a valueless name, but NOT a named value followed by an unnamed value—what makes that last scenario any less useful than all of the others? If anything it's probably the *most* useful, since valueless names and nameless values can already be represented by ul/ol.
