Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 2:07 AM, Gordon P. Hemsley wrote: So perhaps a more useful question would be what to do in situations like that—should mimesniff treat "application/octet-stream" as a type "supported by the browser" for the purposes of sniffing images, audio or video, fonts, or other media types? The way it works right now is that http://www.whatwg.org/specs/web-apps/current-work/#mime-types says: The MIME type "application/octet-stream" with no parameters is never a type that the user agent knows it cannot render. User agents must treat that type as equivalent to the lack of any explicit Content-Type metadata when it is used to label a potential media resource. So for the purpose of sniffing media loads specifically, that type is treated just like no type at all. But first you have to know it's a media load. I imagine this ties in, too, to the issues with sniffing CSS files that has been raised elsewhere: https://bugzilla.mozilla.org/show_bug.cgi?id=560388 https://bugzilla.mozilla.org/show_bug.cgi?id=562377 Neither one of those has anything to do with application/octet-stream as far as I can tell. Those cover cases in which data is sent with either no Content-Type header or with such a header which can't even be parsed as "major/minor". Neither of which is true if the data says "appliction/octet-stream". -Boris
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, Nov 29, 2012 at 1:30 AM, Gordon P. Hemsley wrote: > Based on my reading of the source code, it seems that Gecko treats a > resource served as 'application/octet-stream' as an unknown type which > is sniffed as if no Content-Type was specified. Oh, wait, I forgot what I was reading—Gecko does this specifically in the context of sniffing for an audio or video resource. So, if a resource tagged as 'application/octet-stream' is included in or , for example, it will be treated as unknown for the purposes of identifying its true nature. This never follows a path of scriptable privilege escalation, AFAICT. So perhaps a more useful question would be what to do in situations like that—should mimesniff treat "application/octet-stream" as a type "supported by the browser" for the purposes of sniffing images, audio or video, fonts, or other media types? I imagine this ties in, too, to the issues with sniffing CSS files that has been raised elsewhere: https://bugzilla.mozilla.org/show_bug.cgi?id=560388 https://bugzilla.mozilla.org/show_bug.cgi?id=562377 https://bugzilla.mozilla.org/show_bug.cgi?id=808593 -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 1:30 AM, Gordon P. Hemsley wrote: Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Only for media ( and ) loads. Note that the HTML spec requires this behavior for those. Are there security implications with doing this? In general, yes. Doing this for document loads would be a security nightmare, for example. -Boris
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
There are substantial negative security consequences to sniffing content on MIME types that are commonly used as default fallback values by web servers or web application developers. This includes text/plain and application/octet-stream. /mz
[whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Are there security implications with doing this? Or should I add 'application/octet-stream' to the list of unknown types that currently includes 'unknown/unknown', 'application/unknown', and '*/*' (step 2 of the "media type sniffing algorithm")? Or, given that that step calls the "rules for identifying an unknown media type" with the sniff-scriptable flag set, should it get its own call, with the sniff-scriptable flag unset? Are there other options here? I haven't checked what UAs actually do in practice, but I don't believe the spec currently allows anything but leaving resources tagged as 'application/octet-stream' as they are. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] Deferring javascript download and execution until after onload
Ian, > The only cost there could be is the cost > of executing the script, and it's already trivial to offload that: just > put all the code in a function, then call the function when you're ready. > It's already possible now to design scripts such that they don't run until > you call them, so you could already do this: You ask us not to make duplicate arguments because you say that it just clogs up this list and does nothing to change the outcome of your decision. I would like to ask that you not do the same. You have said this same thing no less than 10 times across various threads and communications. I really don't think anyone who's following this particular issue is unclear about your stance. --- What it boils down to is, you feel that the onus is on the developers of the scripts themselves to change so they are more "performance optimization friendly" for those who use the scripts. There are a number of us who work in the performance optimization consulting arena, and when we consult with a site who's using a bunch of third party scripts, and most of those scripts are not written the way you think they should be, those clients aren't happy when we have to tell them "sorry, your only option to optimize the performance is to make your own modifications to those 3rd party scripts, and then self-host them, and then keep up with merging changes constantly, etc…" or some other such impractical nonsense. Your approach is like tail-wagging-the-dog: let's make sure performance stays less than optimal, so that eventually the designers of these scripts have to wake up and fix it. Perhaps you want to drag this issue out long enough (been under discussion for almost 2 years now) that all those poorly designed scripts across the web are just eventually made obsolete or finally "fixed" without the web platform needing to address it. The rest of us, I think, would like to actually make performance gains and optimizations now. It will be years and years before most of the popular scripts on the web may be rewritten in the way you suggest. It's just a shame that performance has to continue to suffer until then. Giving us a mechanism by which we could load existing scripts written and maintained by others, which we don't control, in a way that is more performant than what we can currently do, regardless of how that script is designed to self-execute or not, would be a very useful tool to us, despite you insisting it's not useful. Also, some scripts, by nature of what they do or how they do it, will ALWAYS have to auto-execute. Consider the feature-tests that jQuery or Modernizr do automatically during their initialization. I think it would hurt both jQuery and Modernizr and others like them if users all of a sudden had to start calling a $.init() or something like that before they could use the script. The untold tens of thousands of sites and books which explain how to use these scripts would all be rendered completely inaccurate if such a major paradigm shift were to happen. --Kyle
Re: [whatwg] Deferring javascript download and execution until after onload
Ian, > The cost of parsing the script can be done async, even off the main thread > in theory, so it's a non-issue. You have asserted many times that parsing is off the main thread, therefore it doesn't matter. That makes the giant (and I think faulty) assumption that the device in question has enough spare resources to give multiple threads, which not all do, and that all threads can run in parallel without hurting each other and/or the overall performance. There have been a number of articles referencing issues where complex scripts do in fact take a non-trivial amount of parsing time on limited mobile devices. Even if such work wasn't strictly blocking the main UI thread, the fact that it may take a lot of processing (or memory) power from the device might very well mean that large parsing tasks could starve necessary resources, so even if it's on another thread, there's still very much not a "non-issue" to consider. I tried quick google searching just now to dig some specific articles up and failed to find what I remembered reading, but perhaps others on the list know what I'm talking about. I recall someone showing that jquery.js took over 1+ second to parse on a mobile device, but I can't remember the exact numbers. I remember being shocked at how crazy long jquery.js took to parse. Here's something though that seems it's related: https://github.com/tolmasky/language/issues/18 Moreover, as has been mentioned many times in various threads (and you seem to gloss over repeatedly), the gmail mobile team passed down large amounts of javascript "hidden" in a javascript /* … */ comment, so as to prevent that large amount of code from being parsed, until "later" when the hit was acceptable, because they felt that the parsing and/or execution was non-trivial enough to unacceptably slow down their app's startup time. IIRC, this was their post: http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html In any case, your assumption that parsing is a non-issue seems to fly in the face of not only some explicit evidence to the contrary, but there have also been some comments in various threads from browser vendor devs that lent credence to the fact that parsing could in fact be somewhat costly. Do you have explicit evidence to the contrary that no such possible performance issues during parsing could possibly exist on any device or with any script in the wild? It would be nice if you could show such contrary evidence instead of dismissing or ignoring the arguments and evidence already out on the table. The coming "module" feature (in ES6 or whatever) could make this worse, because AIUI, the parsing/compilation stage is where the browser will resolve static dependencies, so it's THAT stage which very well might be taking a lot longer while it fetches dependency resources. --Kyle
Re: [whatwg] Adding crossorigin="" to more elements
On 11/28/12 11:03 PM, Boris Zbarsky wrote: Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. Oh, I see. You've added this "taint" thing, which you're using for the CSS bit. I don't believe Gecko has any such concept. We simply fail the load if the CORS check fails. Furthermore, Gecko's behavior is what the CORS spec requires: failure to respond properly to a cross-origin CORS request must be treated like a network error per CORS. -Boris
Re: [whatwg] Adding crossorigin="" to more elements
On 11/28/12 7:42 PM, Ian Hickson wrote: Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. Pretty sure that's not web-compatible... If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 Done. An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. A CORS-enabled load from a server that knows nothing about CORS will throw away the sheet, while a no-CORS load will happily apply the sheet to the page (but not give access to its data). So inheriting the mode can cause drastic changes in behavior compared to not inheriting it... If the CORS mode is inherited from the importing sheet, then I think the "origin" for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. That's not quite correct. It changes the _object_ origin to that of the caller. It doesn't change the _subject_ origin. Otherwise loading something via CORS would allow it to act on behalf of the loading page, whereas usually pages assume that using CORS just gives them expanded access to something. Or put another way, if I have a file:// page that loads a sheet from http:// with CORS, that shouldn't imply that the sheet can then link to file:// URIs the page can link to. This is very important; oversimplifying the security model to the point where it becomes insecure is bad. ;) Maybe this is OK, but it's non-obvious; usually for security purposes the importing sheet is what affects things like can-load checks, Referer headers, etc. Presumably a CORS-same-origin sheet would use the security characteristics of the page, since the page can make the style sheet dance as if it was its puppet. No, see above. The page can make the sheet do whatever, agreed. But this is about the _sheet_ taking on the permissions of the _page_ in some sense, which may not be desirable. Anyway, that part of it belongs in CSS/CSSOM. That's fine by me. Assuming we ever end up with a CSSOM spec not holding my breath. ;) -Boris
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
On Tue, 8 May 2012, James Greene wrote:
>
> The problem [with window.onerror is] that this mechanism does not allow
> us to inspect the pertinent Error object at all: it only provides us
> with three arguments at invocation time: message (string), fileName
> (string), and lineNumber (number). These are rarely useful in practice.
Could you elaborate on what the exception object (Error or DOMException or
whatever) provides that the onerror callback's arguments don't, that you
would find useful for debugging? Is it just the stack trace?
On Wed, 9 May 2012, Simon Pieters wrote:
> >
> > ## My proposal(s) to fix it
> > As such, I propose the following two options as fixes:
> > 1. Add a function like `getLastError` to the global `window` object that
> > would fetch the actual `Error` object associated with the most recent
> > unhandled error. I would foresee common usage looking something like the
> > following:
> > ```
> > var oldOnError = window.onerror;
> > window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
> >if (oldOnError) {
> >return oldOnError(errorMsg, url, lineNumber);
> >}
> > var e = window.getLastError();
> >alert("Globally unhandled error! But we now can discover its origin.
> > Details: " + e);
> >return false;
> > }
> > ```
> > 2. Alternatively (though less preferably), we could also update the
> > invocation arguments of `window.onerror` callbacks to include a new fourth
> > argument that would be the relevant `Error` object itself:
> >```
> >var oldOnError = window.onerror;
> >window.onerror = function myErrorHandler(errorMsg, url, lineNumber, e) {
> >if (oldOnError) {
> >return oldOnError(errorMsg, url, lineNumber, e);
> >}
> > alert("Globally unhandled error! But we now can discover its origin.
> > Details: " + e);
> >return false;
> >}
> >```
> >While this essentially makes the first three arguments useless, I have
> > posed it this way for the sake of backward compatibility.
>
> I'd prefer this second option (except making it the fifth argument),
> because the exception object can become garbage earlier and because for
> cross-origin script errors, the arguments to window.onerror are masked
> for security reasons, and we would need to mask the exception object as
> well, so it seems better to use the same mechanism for that.
I don't really understand the practical difference between these two
options, assuming getLastError() only returns a value while the onerror
handler is being invoked. (If it returns a value after it's invoked, you
get the problem zcorpan describes above, of the value not being garbage
collectable until much later.)
> Also for compile script errors, there is no exception object.
That's a good point also.
On Fri, 11 May 2012, James Greene wrote:
>
> I personally am interested in adding the stack trace, yes, but ideally I
> would just have access to the full "Error" object so I can always have
> an up-to-date model if the "Error" object continues to change (as it
> probably will). For example, some devs may be interested in the "Error"
> object's "name" property, which is already a part of the object today
> but is not provided to "window.onerror" callbacks. And again, if
> additional properties are added in the future, it's just more and more
> properties that may need to get incrementally added to the
> "window.onerror" invocation arguments list.
Having the exception object, if any, in the onerror callback, seems
reasonable, and would indeed limit how many more arguments we may have to
add over the years. It seems that providing it as an argument would be
better than as a global, though.
> For example, I proposed the addition of an "innerError" property (or
> some would call it "cause") for chaining errors and masking internal
> errors that consumers shouldn't see, instead providing a customer-facing
> message.
I'm not familiar with that proposal.
On Fri, 11 May 2012, James Greene wrote:
>
> Alright... so what's next? I'm assuming this needs further discussion
> with other WHATWG members chiming in. If I can help, please let me
> know. I'd like to see this request through.
Discussion isn't really what's needed, so much as commitments (or at
least, positive interest) from browser vendors. See this FAQ entry:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
In general, providing the exception object as a fifth argument to onerror
seems reasonable to me. Any implementors interested in adding this?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Prerendering and APIs
On Mon, 9 Apr 2012, Boris Zbarsky wrote: > On 4/9/12 2:16 PM, Gavin Peters (蓋文彼德斯) wrote: > > However, this is strikingly similar to two other cases: when a > rel=stylesheet ...> element is removed from the document, in WebKit, we > > remove the stylesheet from the document, although this isn't explicitly > > specified in 4.12.5.11, > > http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-stylesheet. > > In this situation, Gecko removes the stylesheet from the document, but > does not stop its load and keeps it in the per-document object cache. > Fwiw. Spec somewhat updated (.sheet now changes to null if you take the or
[whatwg] Adding crossorigin="" to more elements
On Thu, 1 Mar 2012, Robert Kieffer wrote: > > For reasons documented in > https://bugzilla.mozilla.org/show_bug.cgi?id=696301, I�d like to propose > that support for the �crossorigin� attribute be added to SCRIPT tags. > > tl;dr - When applied to window.onerror information, the same-origin > policy makes it near-impossible to host script resources on a CDN, while > simultaneously using window.onerror to gather information about JS > errors. Done. On Tue, 28 Aug 2012, Boris Zbarsky wrote: > > I just added support for in > Gecko.[1] Such links are subject to CORS checks if the load is > cross-site, and the sheet load will fail if the CORS check fails. If > the CORS check succeeds, script in the page will be able to script the > cross-site stylesheet. > > This allows stylesheets served from a CDN to be scripted by the page if > desired, so I would like to propose that we add this feature to the > spec. Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 ...and I'll try to fix it when I update that part of the spec (the CSSOM/HTML coordination). > An open issue: what to do about @import? I haven't done anything magic > here yet. Inheriting the CORS mode from the importing sheet is a bit > weird, and I wasn't quite sure I wanted to make CSS syntax changes at > this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. On Tue, 28 Aug 2012, Boris Zbarsky wrote: > > If the CORS mode is inherited from the importing sheet, then I think the > "origin" for the fetch should be the page, not the importing sheet, > since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. > Maybe this is OK, but it's non-obvious; usually for security purposes > the importing sheet is what affects things like can-load checks, Referer > headers, etc. Presumably a CORS-same-origin sheet would use the security characteristics of the page, since the page can make the style sheet dance as if it was its puppet. Anyway, that part of it belongs in CSS/CSSOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus and Toolbars
There is a hack that allows css to handle clicks using hidden checkboxes and adjacent :checked siblings. Its not terribly suited for menu-type behavior though. Fred Andrews wrote: >Dear Ian, > >Thank you opening a discussion about these interactive elements. It >would be disappointing to see these abandoned, for those who would like >to see more interactive non-javascript content. > >I would note that CSS alone is able to implement styled menus but only >for 'hover to activate' and not for 'click to activate'. Might there >be an alternative approach using a 'click to toggle' property on >elements that might allow CSS alone to implement click activated menus >etc? > >cheers >Fred > >> Date: Wed, 28 Nov 2012 00:12:08 + >> From: i...@hixie.ch >> To: wha...@whatwg.org >> CC: jackalm...@gmail.com; dglaz...@chromium.org; tk...@chromium.org; >rn...@webkit.org; eocon...@apple.com; koivi...@iki.fi; >jan.va...@gmail.com; ad...@apple.com; jon...@apple.com; >sim...@opera.com; hsivo...@iki.fi; jgra...@opera.com; >mou...@lamouri.fr; jo...@sicking.cc; o...@chromium.org >> Subject: [whatwg] Menus and Toolbars >> >> >> (If you're cc'ed, your opinion likely affects implementations of this >and >> so your input is especially requested. See the question at the end. >If you >> reply to this, please strip the cc list as the mailing list software >will >> otherwise block your post for having too many cc's. Thanks.) >> >> There's a big section in the spec that tries to do three things: >> >> * context menus >> * toolbars >> * menu buttons >> >> Right now it's not implemented by anyone, though Firefox has a >variant. >> >>http://whatwg.org/html/#the-menu-element >> >> This section has two big problems: >> >> 1. Styling of toolbars and menu buttons is just not defined. >> >> Toolbars could be a purely stylistic issue, to be solved either >excluively >> by CSS, or CSS plus a component/widget binding model (whatever >solution we >> end up with for that). >> >> Menu buttons are a real widget, though, so we can't just leave them >to CSS >> styling of s, there needs to be some real styling going on. >Right >> now, because of the algorithm mentioned in #2 below, this is very >> complicated. I'll get back to this. >> >> (Styling for context menus is not a big deal, they just use native >UI.) >> >> >> 2. Nobody is implementing it, in particular, the algorithm that >converts >> HTML elements into a menu structure seems unpopular. >> >> Right now, the spec has this algorithm that defines how to map >existing >> HTML semantics to a context menu or menu button (or toolbar, though >the >> latter is less important if we move to a pure-CSS rendering model for > >> toolbars, since we'd just drop the algorithm for them then). >> >> The idea here is that you don't have to use JavaScript to replicate >the >> effects of existing semantics. For example, if you want a menu button > >> which acts as a navigation mechanism, you just put elements in >your >> markup and they automatically get turned into menu items. >> >> There's also a generic element for when you don't need an >> existing element to be used. Firefox essentially only implements >this, >> though it's called in Firefox. also supports an >> attribute that points at other elements to indirectly define >features. >> >> >> To move forward on this, here are some proposals: >> >> #1: Drop and all related features. I don't think we should do >this, >> but if we can't get agreement on what to implement, this is the only >> option left, so it's on the table. >> >> >> #2: A design that supports context menus and menu buttons using >dedicated >> markup, with support for indirect defining of commands. >> >> First, we make take three values: "toolbar", which >just >> means to render the element using CSS (the default value for legacy >pages, >> too), and "context" and "button", which define menus. "context" menus > >> would be hidden by default, "button" menus would render as a button, >> which, when clicked, shows the menu. contextmenu="" can be used to >point >> to a . >> >> The element in "context" and "button" modes would only have >three >> elements as descendants: elements, elements, and > >> elements. (Or maybe no s, and we do separators by using groups of > >> elements without labels.) Other children are ignored. >> >> elements would just have a label="" attribute and, >optionally, >> a command="" attribute. The command="" attribute would work as it >does in >> the spec now, deferring to some existing element. When the menu item >is >> selected, it would fire click on the , and then as a >default >> action do whatever the action of the command="" is, if specified. (We >can >> talk about whether to bother supporting icons in the , and >if so >> how, especially given high-res screens, but that's a minor detail.) >> >> With type=button, CSS would apply to the and >elements, >> maybe with a limited set of properti
Re: [whatwg] Menus and Toolbars
On Tue, Nov 27, 2012 at 4:12 PM, Ian Hickson wrote: > To move forward on this, here are some proposals: > > #1: Drop and all related features. I don't think we should do this, > but if we can't get agreement on what to implement, this is the only > option left, so it's on the table. I'm gonna throw out this option. Worst case, retaining solely for its context-menu additions is necessary - this keeps being requested over and over again by authors, both of small and large apps. > #2: A design that supports context menus and menu buttons using dedicated > markup, with support for indirect defining of commands. > > First, we make take three values: "toolbar", which just > means to render the element using CSS (the default value for legacy pages, > too), and "context" and "button", which define menus. "context" menus > would be hidden by default, "button" menus would render as a button, > which, when clicked, shows the menu. contextmenu="" can be used to point > to a . > > The element in "context" and "button" modes would only have three > elements as descendants: elements, elements, and > elements. (Or maybe no s, and we do separators by using groups of > elements without labels.) Other children are ignored. > > elements would just have a label="" attribute and, optionally, > a command="" attribute. The command="" attribute would work as it does in > the spec now, deferring to some existing element. When the menu item is > selected, it would fire click on the , and then as a default > action do whatever the action of the command="" is, if specified. (We can > talk about whether to bother supporting icons in the , and if so > how, especially given high-res screens, but that's a minor detail.) > > With type=button, CSS would apply to the and elements, > maybe with a limited set of properties applying. Long term, we look to XBL > or Web components or whatever for styling. > > We drop entirely. > > > #2a: Same as #2, except we keep as a way to introduce commands > without using existing elements. I assume that the "button" case is meant to still support toolbars, except that each top-level entry in the toolbar is a separate element? (Thus delegating the actual "toolbar" styling fully to CSS.) > #3: We forget the non-JS case; so, the same as #2, but doesn't > get a command="" attribute. We add radio menu items, checkbox menu items, > and the like, over time, as features on . (Defined much like > has some of them defined today.) > > > #4: We do what the spec has now. > > > #5: We do what the spec has now, except we change the type=toolbar to just > be rendered in CSS (and remove type=list, making toolbar the default). > > > #6: Your idea here. > > > So, implementors: Which of these would you be willing to implement? Are > there constraints I've not thought of? Are there features that we need to > deal with that I haven't mentioned above? Are there use cases that we > should just abandon that could simplify the solution drastically? I'm down with keeping the current "do nothing" behavior, and the "context menu" behavior. I like the proposed "button with pop-up menu" behavior, as a better version of the old toolbar initiative. I have no opinion on the rest of the details, as they seem roughly equivalent. ~TJ
Re: [whatwg] Menus and Toolbars
Greetings, I'm not a browser implementor, but I have been dealing quite a bit with menus and other GUI stuff from the web development perspective; so here it goes some comments I hope implementors might find interesting: I have put a first example on http://std.dragon-tech.org/mainmenu.png All you can see there is doable with plain CSS and HTML. It doesn't even use any CSS3 features. In fact, the whole thing works fine in IE8. As Fred Andrews mentioned, menus are quite easy to achieve with no scripting, as long as one stays within "hover-based" menus. Of course, most of the buttons and items in the screenshot require JS to actually do anything, but that's because of the app's own complexity. All the stuff in that window should be pretty much accessible (everything in there are ul's, li's, and img's with matching @alt and @title for the toolbar, which contains only shortcuts anyway, and load's of @onclick attributes that could be easily replaced by 's with @href's on a more "web-ish" scenario). In summary, menu bars and tool bars are quite a solved problem Now, here is when stuff gets serious: http://std.dragon-tech.org/contextmenu.png To be honest, I hate most of the code behind that with a passion... and I wrote it! I get paid for making stuff work, and thus I make stuff work, no matter what it takes. The context menu requires JS to display at all. It "overrides" the browser's native menu (which sometimes would be useful). There is a huge, empty, transparent div covering the whole iframe (the main area on the screen with the table on it) just so it can catch clicks and dismiss the menu. The "context menu key" (that nice thing between right Ctrl and the "Windows" key) doesn't do anything (doesn't trigger neither my menu nor the browser's) when the iframe has focus. Don't get me wrong, I quite love what I pulled off, and so do most of the app's users; but I loathe the truckload of crap code I have to feed the browser for everything to work as intended. So, in summary, context menus are somewhat achievable with significant scripting, some creativity, and epic x-browser patience; but it's still a problem far from solved. As a web developer, what I'd love to see implemented natively would be: * A mechanism (most probably an attribute + a CSS pseudo-class, or maybe even recycling :hover) to show click-based menu bars some script-less love. * A mechanism to deal with context menus in a sane way. It all boils down to UA's natively handling the showing and dismissing of the menus; and maybe enabling a mechanism to define a default (did you noticed the bolded option at the start of the menu on the screenshot? Yay, double-clicking instead of right-clicking does invoke it, skipping the whole "show the menu" step! ). That would cause it to work with any native method the browser or platform already supports for displaying context menus. As a user, I would hope any context menu implementation grants me the ultimate control on which menu is used (native vs. app-provided). Of course, other users, authors, and developers may have other needs, but I can only talk about the ones that I know about. Re-capping, my needs could be solved with this (element and attribute names are meant to be verbose and descriptive, not practical nor "final"): - A @enable-toggling-hover-state-by-clicking attribute. - A or similar element, plus a mechanism to "bind" it to other elements on the page. As long as the browser deals with show/dismiss logics, I could handle everything else. If it had a @default-action attribute that would be great, but I could live without it (or, more likely, toss in a @data-* attribute, and loop through elements bound to the menu to hack in the double-click handlers). Regards, Eduard Pascual On 28 November 2012 01:12, Ian Hickson wrote: > > (If you're cc'ed, your opinion likely affects implementations of this and > so your input is especially requested. See the question at the end. If you > reply to this, please strip the cc list as the mailing list software will > otherwise block your post for having too many cc's. Thanks.) > > There's a big section in the spec that tries to do three things: > > * context menus > * toolbars > * menu buttons > > Right now it's not implemented by anyone, though Firefox has a variant. > >http://whatwg.org/html/#the-menu-element > > This section has two big problems: > > 1. Styling of toolbars and menu buttons is just not defined. > > Toolbars could be a purely stylistic issue, to be solved either excluively > by CSS, or CSS plus a component/widget binding model (whatever solution we > end up with for that). > > Menu buttons are a real widget, though, so we can't just leave them to CSS > styling of s, there needs to be some real styling going on. Right > now, because of the algorithm mentioned in #2 below, this is very > complicated. I'll get back to this. > > (Styling for context menus is not a big deal, they just use native UI.) > > > 2. Nobody is impleme
[whatwg] iframe sandbox and top navigation
Hi,
while working on https://bugzilla.mozilla.org/show_bug.cgi?id=785310 (block
setting
window.top.location from a document sandboxed without 'allow-top-navigation')
and discussing
the correct behavior with Bobby Holley, I found some interesting differences
between what Chrome and IE have implemented around top navigation and iframe
sandbox.
In my testing with Chrome, if you have a sandboxed document with the same
origin as the top level document and the sandboxed document has
'allow-same-origin allow-scripts',
the sandboxed document can NOT navigate the top level document via setting
window.top.location
ie it's blocked. Bobby pointed out that blocking top navigation when the
sandboxed document
is same origin with the top level document is difficult, since the sandboxed
document
can do window.top.eval('window.location = "http://foo.com";') - this bypasses
the block in Chrome
and the top navigation happens.
In IE 10, at least in the Windows 8 consumer preview which is the latest
version i have at the moment unfortunately, you can set window.top.location
from a document that's same origin
with the top level document which is contained in an ie it doesn't
need allow-top-navigation.
It would be great if the spec could clarify the correct behavior around top
navigation
when the sandboxed document is/is not same origin with the top level document.
One option would be for Chrome/Webkit to also block the window.top.eval
loophole, but in general
we feel that trying to stop this when the documents are same origin would
possibly be problematic.
Another option would be to not block top navigation when the sandboxed document
is same origin
with the top level document (which implies it's been sandboxed with
'allow-same-origin' of course).
>From discussions with Bobby, I think we prefer the second option. The
>restriction on navigating
window.top would only be applied in the cross domain case.
thanks !
ian
Re: [whatwg] Menus and Toolbars
Dear Ian, Thank you opening a discussion about these interactive elements. It would be disappointing to see these abandoned, for those who would like to see more interactive non-javascript content. I would note that CSS alone is able to implement styled menus but only for 'hover to activate' and not for 'click to activate'. Might there be an alternative approach using a 'click to toggle' property on elements that might allow CSS alone to implement click activated menus etc? cheers Fred > Date: Wed, 28 Nov 2012 00:12:08 + > From: i...@hixie.ch > To: wha...@whatwg.org > CC: jackalm...@gmail.com; dglaz...@chromium.org; tk...@chromium.org; > rn...@webkit.org; eocon...@apple.com; koivi...@iki.fi; jan.va...@gmail.com; > ad...@apple.com; jon...@apple.com; sim...@opera.com; hsivo...@iki.fi; > jgra...@opera.com; mou...@lamouri.fr; jo...@sicking.cc; o...@chromium.org > Subject: [whatwg] Menus and Toolbars > > > (If you're cc'ed, your opinion likely affects implementations of this and > so your input is especially requested. See the question at the end. If you > reply to this, please strip the cc list as the mailing list software will > otherwise block your post for having too many cc's. Thanks.) > > There's a big section in the spec that tries to do three things: > > * context menus > * toolbars > * menu buttons > > Right now it's not implemented by anyone, though Firefox has a variant. > >http://whatwg.org/html/#the-menu-element > > This section has two big problems: > > 1. Styling of toolbars and menu buttons is just not defined. > > Toolbars could be a purely stylistic issue, to be solved either excluively > by CSS, or CSS plus a component/widget binding model (whatever solution we > end up with for that). > > Menu buttons are a real widget, though, so we can't just leave them to CSS > styling of s, there needs to be some real styling going on. Right > now, because of the algorithm mentioned in #2 below, this is very > complicated. I'll get back to this. > > (Styling for context menus is not a big deal, they just use native UI.) > > > 2. Nobody is implementing it, in particular, the algorithm that converts > HTML elements into a menu structure seems unpopular. > > Right now, the spec has this algorithm that defines how to map existing > HTML semantics to a context menu or menu button (or toolbar, though the > latter is less important if we move to a pure-CSS rendering model for > toolbars, since we'd just drop the algorithm for them then). > > The idea here is that you don't have to use JavaScript to replicate the > effects of existing semantics. For example, if you want a menu button > which acts as a navigation mechanism, you just put elements in your > markup and they automatically get turned into menu items. > > There's also a generic element for when you don't need an > existing element to be used. Firefox essentially only implements this, > though it's called in Firefox. also supports an > attribute that points at other elements to indirectly define features. > > > To move forward on this, here are some proposals: > > #1: Drop and all related features. I don't think we should do this, > but if we can't get agreement on what to implement, this is the only > option left, so it's on the table. > > > #2: A design that supports context menus and menu buttons using dedicated > markup, with support for indirect defining of commands. > > First, we make take three values: "toolbar", which just > means to render the element using CSS (the default value for legacy pages, > too), and "context" and "button", which define menus. "context" menus > would be hidden by default, "button" menus would render as a button, > which, when clicked, shows the menu. contextmenu="" can be used to point > to a . > > The element in "context" and "button" modes would only have three > elements as descendants: elements, elements, and > elements. (Or maybe no s, and we do separators by using groups of > elements without labels.) Other children are ignored. > > elements would just have a label="" attribute and, optionally, > a command="" attribute. The command="" attribute would work as it does in > the spec now, deferring to some existing element. When the menu item is > selected, it would fire click on the , and then as a default > action do whatever the action of the command="" is, if specified. (We can > talk about whether to bother supporting icons in the , and if so > how, especially given high-res screens, but that's a minor detail.) > > With type=button, CSS would apply to the and elements, > maybe with a limited set of properties applying. Long term, we look to XBL > or Web components or whatever for styling. > > We drop entirely. > > > #2a: Same as #2, except we keep as a way to introduce commands > without using existing elements. > > > #3: We forget the non-JS case; so, the same as #2, but doesn't > get a command="" attr
Re: [whatwg] Support of link rel=prefetch
I can confirm this does not work on Android 4.2 where Chrome is the default browser. In fact, it does not work on Chrome 23 desktop either. Adam, should I fill a bug report on https://bugs.webkit.org/ or http://code.google.com/p/android/issues/list ? I believe this is a Webkit problem. Thanks laurent On Tuesday, November 27, 2012, Adam Barth wrote: > I consider it not working on Chrome for Android a bug. It's something > we'd like to fix. > > Adam > > > On Tue, Nov 27, 2012 at 10:52 AM, Laurent Perez wrote: >> Hi >> >> I'm testing the prefetch attribute of tags described at >> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch >> >> I've only seen it work on Firefox desktop and mobile, on Chrome desktop, >> and on Android 4.0 stock browser. Mobile Safari, Opera, IE10 or Chrome for >> Android do not support it. >> >> Has this feature been abandoned because of lack of vendors interest ? >> >> laurent >> >> >> http://laurentperez.fr >> J2EE tips and best practices > -- http://laurentperez.fr J2EE tips and best practices
Re: [whatwg] A plea to Hixie to adopt
On Wed, Nov 28, 2012 at 4:26 PM, Ian Hickson wrote: > > All of this has already been discussed on this mailing list, so this is > not new information. I would please refer you to the earlier messages on > this topic. In general, unless there is substantial new information, > please don't keep posting on a thread in this mailing list -- the list is > high-traffic enough without us covering old ground (which is unlikely to > result in a different outcome if nothing has changed). > I think there are misunderstandings here - in particular about how blind users perceive a Web page. I was trying to be helpful. It seems the cards have fallen and we will just need to continue authoring and preaching @role=main. Sorry about the noise. Regards, Silvia.
