Re: [whatwg] responsive images srcalt proposal
There are still some pre-loader issues. Google is promoting that the CDN dynamically optimize the content, that the user agent share enough info to allow the CDN to do so - effectively moving a UA function to the cloud and making a service out of it! From a user privacy perspective this is not good. To counter this, any proposal needs to be competitive, and needs to support the pre-loader being able to make the same decisions that the CDN with some UA info could - it does not need to be any better. The element proposal addresses all the use cases. It might be even better if it's srcset also allowed the image height and file size to be specified as in your srcalt proposal, or if at least the parsing of the srcset tolerated other attributes rather than giving up so that is could be extended with other attribute hints in future. Could this be considered for the element proposal? cheers Fred > Date: Sat, 25 Jan 2014 16:25:13 +0100 > From: pghjvanblokl...@gmail.com > To: dhtmlkitc...@gmail.com > CC: wha...@whatwg.org; freda...@live.com; li...@ericportis.com; > rasmusf...@gmail.com > Subject: Re: [whatwg] responsive images srcalt proposal > > Thank all of you for your feedback. > > > For clarification, the srcalt proposal is NOT intended to specify an > (image) pre-loading mechanism. The pre-loading strategy I described earlier > is just a suggestion for an implementation that I came up with to show that > page loading performance does not need to suffer from srcalt, and might in > fact be improved. > > The srcalt proposal is basically just > > > > and the fact that the browser has great freedom in deciding when to load > which image when srcalt is present (even until after the page load event > has been fired). > > The source alternatives (imageN.jpg in the example) are supposed to be > visually identical, and differ only in resolution/quality/file size. > > > I completely agree with Fred that too much emphasis is on pre-loader > optimization, but that is exactly what srcalt intends to avoid. Most of the > other proposals that I read seem to be about spoon-feeding the pre-loader. > Srcalt just tells what image sources are available to pick from. > > > An advantage of srcalt for authors is that they only need to worry about > display resolutions, physical screen size and design breakpoints when they > are writing their stylesheets, and can leave the choice of source to > the browser. > > An advantage of srcalt for users is that they can instruct their browser to > safe bandwidth/increase speed through always loading the smaller sources, > because all sources are supposed to be visually identical (unlike in other > proposals). > > Srcalt leaves switching between visually different images to stylesheets, > treating images and other content equally: > > little bit > of text > > lots of > text > > > I was wondering how people feel about this separation of concerns. In my > opinion having one element representing one conceptually unique piece > of information is superior to the 'it depends on external conditions what > it represents' approach of other proposals (the art-direction/media > features use cases). Anyone like to comment on this? > > > Thank you for reading. > > Josh.
Re: [whatwg] responsive images srcalt proposal
> Date: Sat, 25 Jan 2014 18:21:59 +0100 > From: rasmusf...@gmail.com ... > Device-pixel-ratio can be quite relevant to include in urls; with an 2x > image compression artifacts in lossy formats (jpg, webp) are less visible > which in turn means you can crank up compression without losing visible > quality while getting an image that'll weigh roughly the same as the > equivalent 1x image. It's a very nice trick :) The images might be identical and your proposal does not allow this to be expressed. It might be better to be able to enumerate all available images and to describe each so that the UA can make a choice. cheers Fred
Re: [whatwg] responsive images srcalt proposal
The problem with a prescriptive standard for pre-loading images is that it
might be abused by content authors for other purposes. I would like to see UAs
able to implement a wide range of image loading strategies using the available
information, including ignoring any pre-loading hints, and this might be
necessary for reloading from a cache.
I am open to other ways to specify the available images, and there have been
many proposals.
cheers
Fred
> Date: Thu, 12 Dec 2013 02:13:58 +0100
> From: rasmusf...@gmail.com
> To: freda...@live.com
> CC: pghjvanblokl...@gmail.com; li...@ericportis.com; wha...@whatwg.org
> Subject: Re: [whatwg] responsive images srcalt proposal
>
> I agree with Josh regarding preloading of images though.
>
> I also think that the current proposals are bordering on being too
> cumbersome and verbose.
>
> We could minimize it dramatically if only a url-pattern and the available
> options are exposed instead of a long list of explicit urls:
>
> srcoptions="/path/to/foo-{width}-{height}-{dpr}.{format},320w
> 480w 640w, 1x 1.33x 2x, webp jpg"/>
>
> Wouldn't this sort of thing be much easier to learn/read/write? Both humans
> and machines.
>
> I won't bother you with all the details here - I've tried to flesh out the
> idea in this gist: https://gist.github.com/rasmusfl0e/6727092
>
>
> On Thu, Dec 12, 2013 at 1:53 AM, Fred Andrews wrote:
>
> >
> > Adding 'srcalt' does not seem warranted.
> >
> > The steps seem too prescriptive for a standard, but might represent one
> > possible implementation.
> >
> > I think too much weight is being put on the pre-loader optimization and do
> > not believe this should block a declarative solution that informs the UA of
> > the available image options. Some argue that it is only for the benefit
> > of the pre-loader, that otherwise it could all be done in JS, but surely we
> > are here to settling on declarative HTML that can be used without JS!
> >
> > The src-N proposal appears to be a genuine attempt to meet all the use
> > cases.
> >
> > cheers
> > Fred
> >
> > > Date: Wed, 4 Dec 2013 18:16:39 +0100
> > > From: pghjvanblokl...@gmail.com
> > > To: wha...@whatwg.org
> > > CC: li...@ericportis.com
> > > Subject: Re: [whatwg] responsive images srcalt proposal
> > >
> > > Thanks to some feedback I got, I worked out the preloading algorithm in
> > > some more detail.
> > >
> > >
> > > It will enable efficient preloading of images in my srcalt proposal, as
> > > well as images with the proposed postpone attribute, and improve overall
> > > performance. The algorithm is meant to supersede the simple preload
> > > scanners that are currently implemented.
> > >
> > >
> > > In short, this algorithm will, when downloading is stalled by JS,
> > calculate
> > > layout on a separate DOM as if javascript were disabled, in order to
> > decide
> > > which srcalt, postponed and CSS background images should be downloaded
> > and
> > > with what priority.
> > >
> > >
> > > 1.) Start downloading all CSS, JS, and without srcalt and postpone
> > > attributes (*1). Always reserve one socket for downloading each of the
> > > three file types (*2). Prioritize on CSS and JS.
> > >
> > > 2.) As soon as all CSS and the document source are downloaded, do one of
> > > the following:
> > >
> > > a.) If all JS has finished running, do layout and continue with step 3.
> > >
> > > b.) If JS is still running, build an independent DOM as if javascript
> > were
> > > disabled, do layout on that and continue with step 3.
> > >
> > > 3.) Clear the download queue for images. With the given DOM and layout,
> > > start downloading the required images from CSS backgrounds,
> > > src/srcalt and visible postponed images. Prioritize on images that will
> > be
> > > immediately visible to the user.
> > >
> > > 4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for
> > the
> > > real DOM (possibly altered by JS). Evaluate whether (too many)
> > unnecessary
> > > images (srcalt/postpone/css backgrounds) were downloaded. If so, mark
> > this
> > > for each category (srcalt/postpone/css) in a cache. Next time the same
> > url
> > > is visited, delay downloading this category until JS finishes (*3).
> > >
> > >
> > > *1.) Images without postpone attribute are require
Re: [whatwg] responsive images srcalt proposal
Adding 'srcalt' does not seem warranted. The steps seem too prescriptive for a standard, but might represent one possible implementation. I think too much weight is being put on the pre-loader optimization and do not believe this should block a declarative solution that informs the UA of the available image options. Some argue that it is only for the benefit of the pre-loader, that otherwise it could all be done in JS, but surely we are here to settling on declarative HTML that can be used without JS! The src-N proposal appears to be a genuine attempt to meet all the use cases. cheers Fred > Date: Wed, 4 Dec 2013 18:16:39 +0100 > From: pghjvanblokl...@gmail.com > To: wha...@whatwg.org > CC: li...@ericportis.com > Subject: Re: [whatwg] responsive images srcalt proposal > > Thanks to some feedback I got, I worked out the preloading algorithm in > some more detail. > > > It will enable efficient preloading of images in my srcalt proposal, as > well as images with the proposed postpone attribute, and improve overall > performance. The algorithm is meant to supersede the simple preload > scanners that are currently implemented. > > > In short, this algorithm will, when downloading is stalled by JS, calculate > layout on a separate DOM as if javascript were disabled, in order to decide > which srcalt, postponed and CSS background images should be downloaded and > with what priority. > > > 1.) Start downloading all CSS, JS, and without srcalt and postpone > attributes (*1). Always reserve one socket for downloading each of the > three file types (*2). Prioritize on CSS and JS. > > 2.) As soon as all CSS and the document source are downloaded, do one of > the following: > > a.) If all JS has finished running, do layout and continue with step 3. > > b.) If JS is still running, build an independent DOM as if javascript were > disabled, do layout on that and continue with step 3. > > 3.) Clear the download queue for images. With the given DOM and layout, > start downloading the required images from CSS backgrounds, > src/srcalt and visible postponed images. Prioritize on images that will be > immediately visible to the user. > > 4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for the > real DOM (possibly altered by JS). Evaluate whether (too many) unnecessary > images (srcalt/postpone/css backgrounds) were downloaded. If so, mark this > for each category (srcalt/postpone/css) in a cache. Next time the same url > is visited, delay downloading this category until JS finishes (*3). > > > *1.) Images without postpone attribute are required for the load event. > > *2.) A server might have specific performance problems serving one type of > file. By reserving sockets downloading can continue on the other file > type(s). > > *3.) JS altering the DOM to such an extend that the wrong images got > downloaded is probably quite rare, but this step will counter the bandwidth > penalty after the first visit. Developer modes of browsers should issue a > warning when this occurs. > > > Compared to the current preload scanners, this implementation will: > > > * support srcalt responsive images, > > * support postpone attributes on images, > > * allow for earlier download of postponed images and CSS backgrounds, > > * can prioritize on all images that are immediately visible to the user. > > > In this scenario srcalt images can never start downloading until document > source and all CSS has been obtained. This might result in a slight > performance loss when responsive images are used. However, since most HTML > and CSS downloads fast (once the server starts sending) and CSS is mostly > cached anyway, in practice this will effect only a very few page visits. > > Depending on available bandwidth and user preference, UAs could also > compensate for this delay by preloading a srcalt candidate by making an > educated guess. > > > Thank you for reading, > > Josh
Re: [whatwg] Make the files attribute of the input element writable
> Date: Thu, 17 Jan 2013 20:45:59 + > From: i...@hixie.ch ... > > >> 1) This would make it possible to write JavaScript libraries that > > >> seamlessly scan the current page for and add > > >> integration with Dropbox / Google Drive / Sky Drive etc. I claim that > > >> changing the value is the easiest and most robust method of > > >> achieving this without requiring changes to the main application > > >> code. Asides from providing an easy path for developers to integrate > > >> online storage services into their apps, this change would make it > > >> easy to write bookmarklets / browser extensions that add this > > >> functionality to any Web application. > > > > > > It seems like this use case would be better handled by having the > > > sites offer an API to the browser, similar to Web Intents, for picking > > > a file. That way you wouldn't need to update each site -- every site > > > would support all the drive systems you use. > > > > Yes, but that approach would require deeper application changes. I think > > that adding a couple of
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
Hi Stan, > From: stas...@orc.ru ... > Subject: Re: [whatwg] API for unique identification of devices > (mobile/tablet/pc) ... > First, I don't think it's convenient for users to register themselves > on many sites, which they visit occasionally. If most of the users do this > right now, > it does not mean they are happy with this, this is bacause there is no other, > more simple way (as simple as just clicking on "remember me"). > > Second, user accounts are based on e-mails as a rule, which is not unique at > all, > every user can have multiple e-mails and multiple registrations. Many > web-services > struggle against users' reputation spoofing made via such fake accounts. A Device ID would not in general be unique either because it would be managed by the users browser software which could have features to change the ID, or open a window with a new ID, or export the ID, etc. It's not your computer so not your choice. > Third, I think it's up to a certain web-service design and requirements, if it > needs to identify user accounts or user devices. For example, usage of > the same profile on multiple devices can be a violation of a web-service > license agreement, or a web-service may bind several devices to the same > profile. Multiple browser profiles on the same device do not matter, because > the same device ID will be returned. Moving from one device to another, > or virtual devices - is just the same thing as having multiple devices > considered > above. You could issue users with a controlled device that you own and under restrictive contractual terms and proxy authorization through this. Or perhaps limit service to devices with an ID that is not trivial for users to change. cheers Fred
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] Feedback on Web Worker specification
Dear Ian, Thank you for sharing you views. > Date: Tue, 20 Nov 2012 23:30:50 + > From: i...@hixie.ch > To: wha...@whatwg.org > Subject: Re: [whatwg] Feedback on Web Worker specification > > On Wed, 22 Aug 2012, Jeffrey Pfau wrote: > > > > While working on enhancing WebKit's privacy infrastructure, I noticed > > that shared workers don't have a UA security policy escape clause like > > localStorage and other APIs. The process to create a shared worker does > > not allow UAs to abort creation with a SecurityError if it decides that > > a document, origin, or script violates the UA's security policy. > > Fixed. > > > On Sat, 3 Nov 2012, Fred Andrews wrote: > > > > Feedback and suggestions for appropriate markup to declare web workers > > would be appreciated. > > Workers are only usable from script, so just start them in script. No need > for anything declarative. The use case requires a JS context without DOM access and with restricted API access. Web workers seem the closest match, but this need not be the same as a 'web worker'. > > The use case is a document with JS disabled or restricted so that it can > > not create web workers, yet still wants to create web workers to process > > page input and to update the document. > > If it's been restricted to not run JS, then starting a worker is > pointless, since workers only run JS. Just to clarify, the proposal is to separately control the document JS context and another 'web worker' like JS context. So the document JS may be disabled or just restricted, while the 'web worker' like JS context can still be enabled. The contexts may well even be in different principles. > If it's been restricted from starting Web workers, then it doesn't matter > how the mechanism to start workers is presented, the page still won't be > able to start a worker. It'd be pointless to have a mechanism to block > workers that could just be circumvented. The point is that the parent document JS context has DOM and API access to read potentially private information and if it can use script to create a worker that has access to outgoing channels then it also gains a capability to leak this state. If the work is created by a declarative mechanism then this channel is closed. > > The use case is a document with JS disabled or restricted so that it can > > not use JS to receive a message and update the DOM, yet still wants to > > support AJAX style designs. > > Why would the user disable JavaScript if they wanted the page to act like > JavaScript was enabled? To avoid scripts leaking private state accessible via the DOM and other APIs the user could disable or restrict JS in contexts that have access to the DOM or other APIs. The 'web worker' like context would not have access to the DOM or other APIs and thus not be a security risk and could be allowed access to the web to forward information into the UA secure context. It is also proposed that the 'web worker' like context receive defined intentional input from users. > > For example the document JS may be disabled but a declarative mechanism > > may be defined to enable web workers to be create and these need to be > > able to post changes to the document. > > The whole point of disabling JS is presumably to prevent this, so > allowing it would defeat the point, as far as I can tell. No, the point is to control the covert leaking of UA state. > > A mechanism specific to the need may be better for security. For > > example, being able to bind a HTML element to a specific web > > worker. A general mechanism that allows a message to update any element > > by ID may be less desirable for security. > > I don't understand. What attack scenario are you envisaging? Web page content that includes scripts to covertly read the UA state and leak this to the web. > > Would it be appropriate to add a new attribute to HTML elements that > > allows their inner HTML to be replaced from a received message? > > If JS is enabled, you can replace any element's contents at will. > > If JS is disabled, presumably it's because the author doesn't want the > page to be manipulated in this way. I don't see why they'd like a feature > that circuments JS being disabled. There are contexts in which it is safest to just prohibit JS, such as documents with user input forms, and there is still a use case for these to be able to be updated. Information flowing into a context does not pose a risk of leaking state from this context. Enabling JS in the secure context poses a risk of leaking state out. > > For example, a form in a pa
Re: [whatwg] Checkboxes that control other checkboxes
> Date: Thu, 22 Nov 2012 11:23:19 +0100 > From: derer...@gmx.ch ... > Maybe, instead of adding that kind of functionalities to form elements, > it might be worth thinking of a different way. E.g., define a set of > scripting actions that are considered as very useful for UIs, and have > no security issues, and let UAs execute that kind of scripts even if > scripting is actually disabled, or let UAs offer a user setting such as > "Allow only useful form actions" or whatever. Supporting scripts that can implement a rich UI with reduced security risk is of interest to the work of the W3C PUA CG and some options have been proposed, see: http://www.w3.org/community/pua/wiki/Draft If the sharing of state accessible via the DOM and APIs is seen as a security risk then scripts that can modify input buttons need to have very restricted access to the DOM and APIs otherwise they could implement a UI redressing attack on the input buttons - for example disabling buttons to discriminate against users or changing the buttons to leak state when the form is submitted. If the buttons are being used purely for operations within the UA then they could be controlled by script in a context restricted from access to outgoing communication channels (the PUA Private Context). A prototype proxy implementing these restriction shows that many rich website UI elements can still operate under such restrictions. If the buttons are part of an outgoing form then placing them in a context without JS enabled would seem to be the simplest approach to protect the DOM and API security. One option being explored is to allow a restricted 'web worker' style context to have some limited access to page elements, and since this worker does not have general DOM access the risk of leaking state is reduced. For example, the check box could have a declarative attribute that defines a message to post to a worker when it changes, and the controlled checkbox could have a declarative attribute that defines a message listener that can change the element. The form UI logic and would be implemented in the worker. Another alternatively is to place the form in an iframe with JS disabled, but with a declarative extension that allows the form state to be posted to the worker upon a change in the checkbox or other defined state changes. The worker could implement the form state logic and post back new iframe content with the controlled buttons enabled or disabled as necessary. The worker is effectively a local web server using messages to receive requests and send responses. An advantage to this approach is that the form could have a fallback URL so that a server could implement the logical even if the UA does not support JS. If targeting UAs without JS then a polyfill is not an option for backwards compatibility and so forms would still need a fallback for legacy UAs. Have you though how this might work? Perhaps include an 'update' button in the webpage design that posts the form to the server? cheers Fred
Re: [whatwg] Enabling LCD Text in 2D canvases.
The canvas that scripts draw into could be over-sized with the UA down sampling this to fit the target size and taking into account the sub-pixel screen layout when doing so. cheers Fred > Date: Wed, 14 Nov 2012 11:09:49 -0500 > From: ju...@chromium.org > To: rob...@ocallahan.org > CC: whatwg@lists.whatwg.org > Subject: Re: [whatwg] Enabling LCD Text in 2D canvases. > > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan > wrote: > > > On Mon, Nov 12, 2012 at 2:36 PM, Justin Novosad wrote: > > > >> Any thoughts? > >> > > > > We'd have to define what happens when you use subpixel antialiasing > > "incorrectly", because we can be pretty sure authors will use it > > incorrectly and expect to get interoperable behavior. > > > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer > > RGBX (initialized to solid black) and enables subpixel antialiasing for > > most text drawing. That might be enough to address your use-cases. > > > > > On top of that, subpixel antialiasing would have to get turned off if a > rotation or scale (or any transform that breaks pixel alignment), is > applied to the canvas element. > > That is an interesting solution but it is still not 100% safe from the > author's perspective, since there are still several use cases that could > cause artifacts (e.g. applying transforms post rasterization) Even with > this feature, it still requires a lot of care to do everything right 100% > of the time. For example, suppose the page gets zoomed after the canvas > contents were rendered. > Advanced authors will be able to deal with this by triggering a canvas > re-draw, they might even preserve subpixel AA by resizing the canvas and > applying a reciprocal scale to bring the canvas element's effective zoom > back to 1. > > Given how 2d canvas currently works, I don't see any killer solution that > would allow subpixel antialiased text without any caveats. > Are there precedents for exposing features with documented caveats? > (excluding caveats that were discovered after the fact) > > Anyone with brilliant ideas: please speak up! > > Thanks, > > -Justin > > > > Rob > > -- > > Jesus called them together and said, “You know that the rulers of the > > Gentiles lord it over them, and their high officials exercise authority > > over them. Not so with you. Instead, whoever wants to become great among > > you must be your servant, and whoever wants to be first must be your > > slave — just as the Son of Man did not come to be served, but to serve, > > and to give his life as a ransom for many.” [Matthew 20:25-28] > > > >
Re: [whatwg] Declarative web worker creation and communication?
Hi Andrew, Thank you for the feedback. The PUA 'shared context' will likely need to be a distinct web worker variant to cater for any required restrictions and also to ensure it does not entangle its specific requirements with other innovations to web workers. However the message API may be reusable, and trying to avoid gratuitous differences seems a worthy goal. Some concerns (lack of understanding) I have with the Web Worker spec. at: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html "9.2.3 The worker's lifetime ... Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o." Does this mean that the Document object of the caller is made available to be web worker? I can't see an interface to it? "9.2.4 Processing model ... 5. A new script is now created, as follows. ... Set the script's browsing context to owner browsing context. ... Set the script's document to owner document." There does not appear to be an API to actually effect the owner browsing context or document? Is this just laying a foundation for future work? Are web workers expected to someday be able to cause navigation of the creators browsing context etc? "9.3 APIs available to workers ... The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification." Are there plans to allow web workers access to the DOM of their creator? Does this apply to documents created by the web worker, such as via XHR? Looking at the source code for some implementations will help clarify the current state, but it would also be of interest to know of planned web workers extensions? cheers Fred > Date: Mon, 5 Nov 2012 10:41:00 +0100 > From: atwil...@google.com > To: freda...@live.com > CC: wha...@whatwg.org; sim...@opera.com > Subject: Re: [whatwg] Declarative web worker creation and communication? > > On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews wrote: > > > Hi Simon, > > > > The use I have in mind is a work-in-progress, see: > > http://www.w3.org/community/pua/wiki/Draft#Examples > > > > However the HTML standard already permits a UA to disable JS, and there is > > the iframe sandbox, or CSP, or browser extensions, to disable JS. I would > > like to make any extensions as widely applicable as possible in the hope of > > building support for them, and think there is a good case for a web > > application with document JS disabled that can still communicate with web > > workers to implement AJAX style designs. > > > > I guess I'm not convinced that a web worker (which has an architecture > designed for asynchronous background processing) is the right vehicle for > your "shared context" idea. My concern is that you're looking at the > limited APIs currently available to web workers, and concluding that this > makes them similar to shared contexts, when in reality the primary driver > behind the limited worker APIs is thread safety, not UA privacy. > > > > > > The aim is not to work around JS being disabled, but to allow web pages to > > be designed with document JS disabled that still support a lot of features > > that are currently handled by the document JS. > > > > After giving it some more thought it would seem best to add new attributes > > for communication with web workers so that the existing attributes could > > implement a backup using a HTTP request - this might help support backwards > > compatibility or allow content to degrade gracefully if web workers are not > > supported. For example, if a form is declared to be submitted to a web > > work via a message post then it could also have a backup 'method' and > > 'action' to make a HTTP request to a server. > > > > The best path for supporting DOM updates from received web worker messages > > is not so clear to me. Perhaps an iframe, or a more general element > > extension that allows an innerHTML update to be received from web worker > > messages and perhaps from server sent events. > > > > cheers > > Fred > > > > > To: wha...@whatwg.org; freda...@live.com > > ... > > > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews > > wrote: > > ... > > > > 1. Declarative web worker creation. > > > > > > > > Feedback and suggestions for appropriate markup to declare web workers > > > > would be appreciated. > > > > > > > > The use case is a document with JS disabled or restricted so that it > > can not > > > > create web workers, yet still wants to create web workers to process > > page > > > > input and to update the document. > > > > > > Can you give some concrete examples where JS is disabled or restricted? > > > > > > -- > > > Simon Pieters > > > Opera Software > > >
Re: [whatwg] Declarative web worker creation and communication?
Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP request - this might help support backwards compatibility or allow content to degrade gracefully if web workers are not supported. For example, if a form is declared to be submitted to a web work via a message post then it could also have a backup 'method' and 'action' to make a HTTP request to a server. The best path for supporting DOM updates from received web worker messages is not so clear to me. Perhaps an iframe, or a more general element extension that allows an innerHTML update to be received from web worker messages and perhaps from server sent events. cheers Fred > To: wha...@whatwg.org; freda...@live.com ... > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews wrote: ... > > 1. Declarative web worker creation. > > > > Feedback and suggestions for appropriate markup to declare web workers > > would be appreciated. > > > > The use case is a document with JS disabled or restricted so that it can > > not > > create web workers, yet still wants to create web workers to process page > > input and to update the document. > > Can you give some concrete examples where JS is disabled or restricted? > > -- > Simon Pieters > Opera Software
Re: [whatwg] Declarative web worker creation and communication?
Hi David, The use case really is to be able to use web workers rather than the document JS. An extension to disable or restrict the document JS will also be added. The design is intended to limit a large range of security issues. cheers Fred > Date: Sat, 3 Nov 2012 11:38:11 +0100 > From: bruan...@gmail.com > To: freda...@live.com > CC: wha...@whatwg.org > Subject: Re: [whatwg] Declarative web worker creation and communication? > > Le 03/11/2012 02:29, Fred Andrews a écrit : > > 1. Declarative web worker creation. > > > > Feedback and suggestions for appropriate markup to declare web workers > > would be appreciated. > > > > The use case is a document with JS disabled or restricted so that it can not > > create web workers, yet still wants to create web workers to process page > > input and to update the document. > If JS is disabled, it's probably to prevent processing of page input > (among other things). > > David
[whatwg] Declarative web worker creation and communication?
1. Declarative web worker creation. Feedback and suggestions for appropriate markup to declare web workers would be appreciated. The use case is a document with JS disabled or restricted so that it can not create web workers, yet still wants to create web workers to process page input and to update the document. For example, would a meta element be appropriate: 2. Declarative message handlers that update the DOM. Feedback and suggestions for appropriate markup to declare points in a HTML document that could be updated from received messages would be appreciated. The use case is a document with JS disabled or restricted so that it can not use JS to receive a message and update the DOM, yet still wants to support AJAX style designs. For example the document JS may be disabled but a declarative mechanism may be defined to enable web workers to be create and these need to be able to post changes to the document. A mechanism specific to the need may be better for security. For example, being able to bind a HTML element to a specific web worker. A general mechanism that allows a message to update any element by ID may be less desirable for security. Would it be best to use an iframe for all such use, perhaps using a new URL that specifies a message target? Would it be appropriate to add a new attribute to HTML elements that allows their inner HTML to be replaced from a received message? 3. Declarative user input message posts. Appropriate markup for declaring events to pass to web workers via messages is also being considered, and feedback on this would also be appreciated. For example, a form in a parent document with document JS disabled that still wants to be able to post a submitted form to a web worker for processing, or posting a message when a button is clicked. For a form, perhaps a new form 'method' could be defined, say 'postmessage', or perhaps a new URL scheme in the form 'action' would be adequate? For a button a new URL scheme might be adequate for declaring a web worker as the target. Perhaps new HTML element attributes would be more appropriate? Such usage may be rather different to typical HTTP URLs, as there may be no response, but this may well suit the use and the web worker could use the above mechanisms to post changes back to the document. Would it be better to define a response message? 4. Accessibility There may be some potential to associate posted messages from UI elements with key short cuts or other input to support accessibility. Having declared points in the document that can receive updates may also help accessibility, and perhaps a description could be added. For example a element that receives email message updates could have a description such as 'Email' and a reader support tool could then report the event to the user. A web page with active content that separates presentation from processing using a non-JS document of presentation and web workers for processing with a restricted set of messages may also help support accessibility. Perhaps accessibility it is already well supported. Feedback from people with experience in this area would be welcomed. Is anyone aware of any related work? cheers Fred
Re: [whatwg] Features for responsive Web design
If it is really necessary to support this case then perhaps both the image width and the the native pixel breakpoints could be specified in the srcset. Then srcset="low.jpg 10w 20w, hi.jpg 20w 40w, huge.jpg 30w" would mean: low.jpg is 10 pixels wide and use it if the native pixel width of the image box is less than or equal to 20, hi.jpg is 20 pixels wide and use it if the native pixel width of the image box is less than or equal to 40, huge.jpg is 30 pixels wide and use it if the native pixel width of the image box is less than greater than 40 pixles The default break points could be the image sizes, and would typically not be needed. The first image could be the 1x density image, allowing the browser to determine the image box size if not otherwise specified and this could be done before loading the image. This approach may be more natural for a fluid design. cheers Fred > Date: Thu, 18 Oct 2012 08:31:57 +0200 > From: i...@anselm-hannemann.com > To: freda...@live.com > CC: whatwg@lists.whatwg.org; odi...@opera.com > Subject: Re: [whatwg] Features for responsive Web design > > Am Donnerstag, 18. Oktober 2012 um 04:05 schrieb Fred Andrews: > > This is good point. Could I just clarify my understanding with an example: > > > > Given a thumbnail image with srcset: > > srcset="low.jpg 20w, hi.jpg 40w, huge.jpg 80w" > > > > The webpage may want to have the browser scale the 20w image to say 50px > > without the browser deciding that the 40w image is more appropriate? > > > > Perhaps it would be realistic for this case to simply not be supported. > srcset cannot support this case. This is one case (of many) why we suggested > picture-element. > > Authors have the alternative option of using an encoding with a lower > > quality > > to reduce the image file size, rather than supplying a low resolution image > > that > > the browser scales up. > > > > Perhaps when the file size is far more important than image quality a > > single image > > would suffice anyway. > > > > > > I don't think that is an answer for such a problem. It is how you would solve > it today. Not how you want to solve it. > > Cheers > -Anselm > > > > cheers > > Fred > > > > > To: whatwg@lists.whatwg.org (mailto:whatwg@lists.whatwg.org) > > > Date: Mon, 15 Oct 2012 18:40:21 +0200 > > > From: odi...@opera.com (mailto:odi...@opera.com) > > > Subject: Re: [whatwg] Features for responsive Web design > > > > > > On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst > > (mailto:derer...@gmx.ch)> wrote: > > > > > > > This is why I'd humbly suggest to put information on the image in > > > > @srcset rather than info on the device and media. Such as: > > > > srcset="low.jpg 200w, hi.jpg 400w, huge.jpg 800w" > > > > > > > > > > > > > What about an image gallery, when you have 25 thumbnails on one page? I'm > > > > > > not sure how this will work in cases where you don't want the image to be > > > > > > the "max size" your screen can handle. > > > > > > Even the common case of having an article picture that is not 100% of the > > > > > > screen width will be hard to do in a responsive non-fluid way with > > > predefined breakpoints. > > > > > > -- > > > Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, > > > http://opera.com > > > > > > > > > > > > >
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
Hi Ian, Thank you for taking the time to follow up. Some of my comments do seem a little immature in hindsight and I tend to agree now that adding a lot of these suggestions to the HTML spec. would make little difference. I am exploring options to reduce the potential for UA state leaks but do not have anything concrete to propose yet. If you care to see some ideas being explored then please see: http://www.w3.org/community/pua/wiki/Draft I could certainly use some feedback. Perhaps someday it will be possible to propose some extensions to better secure the UA state such as new iframe sandbox flags etc. I grew up with computers being personal and private places and we only shared data explicitly. I wince when I see children using the modern web browsers as a platform for computing - knowing the visibility external resources have over their actions. I'll do what I can to try and provide a more secure and private UA option. cheers Fred
Re: [whatwg] Features for responsive Web design
This is good point. Could I just clarify my understanding with an example: Given a thumbnail image with srcset: srcset="low.jpg 20w, hi.jpg 40w, huge.jpg 80w" The webpage may want to have the browser scale the 20w image to say 50px without the browser deciding that the 40w image is more appropriate? Perhaps it would be realistic for this case to simply not be supported. Authors have the alternative option of using an encoding with a lower quality to reduce the image file size, rather than supplying a low resolution image that the browser scales up. Perhaps when the file size is far more important than image quality a single image would suffice anyway. cheers Fred > To: whatwg@lists.whatwg.org > Date: Mon, 15 Oct 2012 18:40:21 +0200 > From: odi...@opera.com > Subject: Re: [whatwg] Features for responsive Web design > > On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst wrote: > > > This is why I'd humbly suggest to put information on the image in > > @srcset rather than info on the device and media. Such as: > > srcset="low.jpg 200w, hi.jpg 400w, huge.jpg 800w" > > What about an image gallery, when you have 25 thumbnails on one page? I'm > not sure how this will work in cases where you don't want the image to be > the "max size" your screen can handle. > > Even the common case of having an article picture that is not 100% of the > screen width will be hard to do in a responsive non-fluid way with > predefined breakpoints. > > -- > Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
> From: m...@apple.com ... > > My point is, that any device-specific notation, such as "2x", forces the > > author to make decisions that the browser should actually make. The author > > does not know if in a few years the image will be viewed with 1.5x or 3x or > > 7x or whatever devices. > > > > This is why I'd humbly suggest to put information on the image in @srcset > > rather than info on the device and media. Such as: > > > > srcset="low.jpg 200w, hi.jpg 400w, huge.jpg 800w" > > > > Where "200w" is the actual image width and not the viewport width. Like > > that every browser can decide which source to load based on the display, > > and available bandwidth or user setting or whatever. > > The benefit of declaring a scale factor is that the browser can rescale each > version of the image to be a consistent size in CSS pixels. Declaring the > width of the image does not tell the browser how much that version should be > scaled. The browser could guess based on ratios between the different > specified widths, but it seems like that would make the problem you describe > worse - the author would still have to understand device pixel densities but > would only be able to specify them to the browser in a mysterious and > indirect way. This does seem to be an important point. Would the follow be a correction understanding of your point: if there are a range of images each with a different declared size and the CSS pixel size of the image is not constrained then the browser must use the image pixel size to determine the CSS pixel size and without knowing the density then this can not be done uniquely? Perhaps the 1x density image could be placed first in the list, and then the densities would all be defined. Having the widths declared may have an advantage when the CSS pixel size of the image is known before the image is loaded because in this case the appropriate image can be determined without needing to load an image to read the size. Alternatively perhaps rather than interpreting the density multiplier as a media query, it could be viewed as a density scaling factor, with the 1x scaling image being the default hint for a 1x density display. The browser would then be free to choose to use any available image as necessary and may reload a different image if the image box size changes or upon zooming. Then again, perhaps I have misunderstood your point. For fluid design the elements are typically designed to adapt to the available size and having to include media query viewport widths in the srcset is equally problematic - a designer knows the images sizes but does not want to be thinking about the viewport widths. A fluid design would probably have little or no media queries based on the viewport width. cheers Fred
[whatwg] Covert sharing of user agent state.
A proposal has been submitted to create a w3c community group to engineer solutions to reduce covert sharing of user agent state. One more sponsor is currently needed to get this group started, so if this issue if of interest to you then please see: http://www.w3.org/community/groups/proposed/#pua The goals of the group are largely technical and the motivation is actually outside the scope of the work but some reasons to be interested in this work are to reduce the fingerprint surface and to draw a line between the open web and the privacy of our personal computer. Currently JS can access a lot of information that identifies our online presence and can leak this out through a range of back channels, and there are other sources of leaks. This information is being used to track our inline presence and solutions such as DNT are only effective if respected. This information could also include a snapshot of your web page complete with the effects of any local customizations or extensions - you webpage is hardly private. With the web becoming a platform to deliver applications this leaky design becomes an even great threat to our privacy. Further new web standards are being built on this leaky standard and have no motivation for considering the covert sharing of UA state and are just adding to it. The technology to preserve our privacy is even being patented which could have rediculious effects. The burden on sponsors should be relatively low as the matters are largely engineering and much of the work is expected to take place in a public mailing list. Developing the designs in public under the W3C Patent Policy may help protect against patents on such technology and help bring better awareness of the issues and solutions to other groups. Help sponsoring this group would be appreciated. The new group will not be addressing privacy policy matters or mechanisms for users to declare tracking or privacy preferences to servers or content providers. The group will focus on engineering solutions to reduce the covert sharing of the UA state and it is expected that proposals will be largely testable against their effectiveness at achieving this while preserving functionality and convenience for users. It would appear that these goals can not be achieved without some restrictions which will inevitable cause some loss of functionality. The development of designs and extensions to mitigate such loss is proposed to be within the scope of the group. Some examples of the approach I advocate as a starting point may help you decide if they wish to be involved: * Javascript has access to a wide range of information about the UA and has access to communication channels to leak this information. Limiting access to such information and/or limiting the back channels will be explored. For example, development could proceed by limiting JS from access to any back channels. This would result in a lot of loss of functionality, but from this staring point we could develop designs and extensions to mitigate some of the loss of functionality. For example, exploring if any access can be reopened on account of users having explicitly knowledge of the transmission of the information. An example extension might be a declared schedule of resources to load that could replace JS that is currently used to load images for sideshows or used to load resources for animated or revolving advertising. Such a restricted user agent could still support general browsing and content consumption, online shopping and payment, online banking, blogs, and a range of JS powered web apps. It would certainly be more functional than a UA with JS disabled. Web apps that depend on JS pulling in resources, such as AJAX designs, would not be supported with such restrictions, however the group could explore extensions to replace common patterns of lost functionality. * CSS media queries can expose private UA information by selectively loading resources. This could be solved by loading all resources before media queries are applied and developing alternatives to media queries. For example, dependence on a media query for the selection of high contrast or black and white images might be reduced by a CSS extension to declare image color and contrast transforms that would suit such devices. There are obviously lots of other areas to address and scrutinize for leaks, but this should gives some idea of the general approach. If you can help in some manner your participation would be welcomed. cheers Fred
Re: [whatwg] Features for responsive Web design
> From: smyl...@stripey.com ... > > > > > > > set="image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, > > > > image-1280x800.jpg 1280 800 150k"> > > > > > > The layout size of that element is not computable until all > > > external stylesheets have loaded, as you have written it. > > > > Actually, the image width is '10em' in this example, without having to > > load any style sheets! > > And how big is 10em? 1em is dependent on the font-size of the parent > element of the , which may be set by an external style-sheet. Good point, thanks. But I don't think this weakens any of the technical points. Having the image sizes declared inline can only help speed the layout computation and allows the browser to use higher resolution images when needed. > > The browser can immediately determine the image to use and load it in > > this particular case. > > You see how easy it would be for authors to get this wrong, even if they > knew they had to put image sizes in-line in order to have good > performance and tried to do that. That you, the promoter of the feature, > can't even get it right suggests that it would also be hard for authors > to do so. If authors can get the URL right then they can get the sizes right. Web browser developer tools could warn if a mismatch is found - which is not something that could be done to correct incorrect media queries. There is likely a better syntax, and there have been lots of ideas proposed. John Mellor proposed the syntax: which has less values and thus less opportunity for user error. Would this help? If you have a better proposal to address the issue then please put it forward? Note that media queries can not solve this problem because the image layout size depends on styling, but media queries should be usable with any solution. cheers Fred
Re: [whatwg] Features for responsive Web design
> From: m...@apple.com ... > >>> I have always been comfortable with the 'x' part of srcset, but the w > >>> and h part felt somewhat wrong to me. What you'd really want to consider > >>> when deciding which image to pick isn't the size of the viewport itself, > >>> but the size available for the image once the rest of the layout is > >>> taken into account. > >> > >> Yeah. That's how I originally designed srcset="", actually, but it was > >> pointed out to me that that's impossible to implement because at the time > >> the browsers need to pick an image, they haven't yet gotten the style > >> sheet so they don't know what the layout will be. > >> > >> (Note that the media-query-based solutions have the same problem.) > > > > If people are really concerned about this latency then they can inline the > > style so that the image layout size is known before other resources are > > available - this may just be the image CSS pixel size and many of these > > proposals require this to be included anyway. > > That's not really a viable solution. Many authors take little care i making > their pages load fast, but browser implementors still consider it important > to load them fast. Yes, the load time is important, and if the images is chosen based only on media queries than it can be loaded immediately. However the loaded images may not be an appropriate resolution - too small with not enough detail or too larger slowing page load. > > It will also help with backwards compatibility to have the style available. > > For example: > > > > > > > > The dimensions here are in image pixels, not CSS pixels. The set would > > include the 'src' image to give the declared image pixel size. The byte > > size and perhaps height could be optional. > > The layout size of that element is not computable until all external > stylesheets have loaded, as you have written it. Actually, the image width is '10em' in this example, without having to load any style sheets! The browser can immediately determine the image to use and load it in this particular case. I understand your point though. The layout size of the element can even change after loading all resources as the user zooms or interacts with the content. Currently there is only one image choice, and it may be too large which would delay loading or too small and lack detail. The latency caused by style sheet loading is something accepted long ago. Pages that need the faster load times, such as landing pages, are going to inline the style, and perhaps even images. Websites for which visitors are expected to browse many pages would have common style sheets that would be cached and available immediately after the first visit. > > In other cases, browsers could either delay loading the image or lookup the > > 'src' image in the set to obtain the declared image pixel size and use this > > to speculatively load an image (once the image viewport size is finalized > > the browser could then decide if a higher resolution image is needed and > > load it then if necessary).Browsers will need to be prepared to reload > > a higher resolution image anyway in case of zooming in. > > Speculatively loading the wrong image does not strike me as an implementation > approach that we'd be interested in. > > Page loading performance is very important to users, and therefore to browser > implementors. I think it's important to avoid defeating important existing > optimizations when adding new features. Consider that it will give the layout engine the image size before the images are loaded, because the sizes are declared inline. This could significantly reduce layout delays. Knowing the layout earlier could help make better decisions about image load order. Further, the layout engine may well be able to load a smaller lower resolution images, reducing load times. Page load times could be faster than they currently are by firstly loading the lowest resolution images - and it would even be more practical to inline these in data: URLs. Users may well prefer to have pages load faster with low resolution images and accept the delay waiting to higher resolution images to load. There do appear to be opportunities to achieve even faster page load times, and a better user experience. Perhaps you could take another look at the issues and opportunities. cheers Fred
Re: [whatwg] srcset isn't future-friendly to screen size differences
> From: sim...@opera.com ... > On Fri, 07 Sep 2012 06:07:30 +0200, Fred Andrews wrote: > > > > > > >> From: jackalm...@gmail.com > > ... > >> I'm not sure how best to solve this, but John Mellor suggested > >> allowing the specification of the image's native dimensions somehow. > >> That way, the browser could know that the 1600.jpg image is > >> appropriate to serve as an 800px wide high-dpi image, or a 1600px wide > >> low-dpi image. > > > > John has a proposal here: > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036958.html > > > > e.g. '' . As I understand it John's proposal only declares the > > image sizes and is not intended for making a selection based on density > > or screen size directly? > > If what's necessary here is to declare the intrinsic dimensions, why not > use the width="" and height="" attributes for this? (They can be > overridden with CSS if you want e.g. 100% width.) The aim is to declare the available raw image sizes so that the browser can choose the most appropriate image to use. That is, the image 320x120.jpg is 320 pixels wide and 120 pixels high, the image 640.jpg is 640 pixels wide and 240 pixels high, etc. This is not intended to specify the CSS pixel size the that image will occupy. The width="" and height="" attributes may well be used to specify the CSS pixel size of the image in the layout. If the width and height of the element are not given then the browser will need to consult the raw image size and I presume John intends the first size to be the CSS pixel size in this case - for higher density screens the browser could then choose a higher resolution image from the set. There are a few other proposals with a similar intent. cheers Fred
Re: [whatwg] srcset isn't future-friendly to screen size differences
> From: jackalm...@gmail.com ... > I'm not sure how best to solve this, but John Mellor suggested > allowing the specification of the image's native dimensions somehow. > That way, the browser could know that the 1600.jpg image is > appropriate to serve as an 800px wide high-dpi image, or a 1600px wide > low-dpi image. John has a proposal here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036958.html e.g. '' . As I understand it John's proposal only declares the image sizes and is not intended for making a selection based on density or screen size directly? I like John's proposal. It would solve the problem of choosing an appropriate resolution image and is simple. What are the issues here? You would still be able to use media queries to further customize image choice for particular screen sizes. Note that there are other design approaches such as fluid design in which you may well avoid media queries. Media queries do seem like a stop gap measure until better fluid design support is developed . For example, if you have only four orthogonal media properties that are significant to an image, each with only two significant ranges, then you need 2^4 or 16 images. With demands to add more and more media queries it should be clear that this approach is a dead end. > It is possible to address this by repeating the same image at a larger > breakpoint, like: > > No. > However, this means you're duplicating data, and have a chance of > failing to update all of the urls when you update one. It also > becomes more hostile as future screens arrive with higher resolutions. > For example, if 3x screens showed up, one would have to write the > following to serve things in the most ideal manner: > > > > At this point it's just silly, and very error-prone. It's just not a good solution for this problem. We still need Johns proposal to address fluid designs. There are two distinct proposals, and if there is no agreement then perhaps it would just be best to split them to allow development to proceed. cheers Fred
Re: [whatwg] Security restriction allows content thievery
> > I'm currently building an analysis system like Google Analytics, which
> > gets embedded into a website via a small JavaScript snippet. When I
> > analyzed the data, I came across a very interesting trick because I got
> > a lot of requests (with the data from location.href) where the entire
> > website was embedded into a data:text/html URI - except that all ads of
> > the page were replaced. Fortunately, my tracking code has been left
> > without modifications.
>
> Weird.
Perhaps the concern is that content has been copied into a data: URL in
violation of copyrights and used to obtain Ad revenue. However the content
could very well be used with permission. Ads are dynamic and do change on
otherwise static content pages. Thus this could well be an honest use of
technology. It would be interesting to know if the search engines actually look
at content in data: URLs - if not then the 'copied' content would seem to bring
little advantage.
Or perhaps the concern is just that it thwarts efforts to track the referer.
> > But the scary thing is that this way you can monetize foreign content by
> > simply embedding it somewhere you can direct traffic to. That's pretty
> > clever, because the original site owner doesn't notice this abuse due to
> > the fact that top.location.href isn't readable. Or even worse, he would
> > never notice it at all when he doesn't sniff the URI with JavaScript,
> > because image files would have no referrer.
> >
> > My final approach to convict the abuser is based on the fact, that the
> > JavaScript was dynamically loaded from my server and that I can write to
> > location.href. So I added this piece of code:
> >
> > if (top.location.protocol === 'data:') {
> > top.location.href = 'http://example.com/trap/';
> > }
> >
> > But even then the referrer will not be passed to the server. So my
> > proposal is that the data URI schema gets an exception on this security
> > behavior.
>
> I don't understand. What referrer are you trying to set? To what?
I think the aim is to have the URL of the page that includes these data: URLs
sent to the tracking server?
I can't see any technical issues raised here?
Some think trackers are 'scary' and consider user privacy and safety more
important, and would prefer to not send a referer and to even have such
Javascript sandboxed so that it can't leak private information.
cheers
Fred
Re: [whatwg] Features for responsive Web design
port can be entirely orthogonal to the required image pixel size. This website could benefit from a set of images with the same aspect ratio but different image resolutions. It could also benefit from some JS to center and scale these images to keep them centered on points of interest (to avoid cropping off a subject heads) - but again this is orthogonal to the required image sets. > On Sat, 25 Aug 2012, Fred Andrews wrote: > > > > Agreed. The width and height of the images is what is needed. The > > browser needs to fill pixels so needs to know the sizes of the available > > images in pixels. > > > > Forget the x scale descriptions and all the other proposed extensions > > and just include a set of images with their pixel height and width. > > Forget dpi etc, its just not needed for this. > > I don't understand this proposal at all. Can you show a concrete example > of how you see this working? Please see the example above. ... > > Image cropping and centering is something best left to JS algorithms. > > Fluid cropping and centering may need an algorithm that takes into > > account particular areas of interest and focus within an image, and user > > choices which would be better handled within the webpage and not at the > > browser level. A web gallery may allow visitors to choose to scale > > versus crop images and to pan cropped image. > > Actually panning and so on would presumably best be done using . I > don't think we need to be providing a declarative way to do this. This does seem to conflict with the srcset proposals 'artistic' choice of image crops. Btw is not necessary for panning and cropping, the image can be positioned through styling and this can be modified by JS based on buttons or mouse movement etc. cheers Fred
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
> From: bhawkesle...@googlemail.com > Date: Wed, 29 Aug 2012 21:25:07 +0100 ... > >> > For example a lot could be done with data-flow computations. > >> > >> Are you talking about something like the "calculate" property from XForms? > > > > Something that could handle simple event processing such as drop down menus > > Already got it. See , , and @contextmenu. These all seem to require the use of Javascript to actually handle the click event? The suggestion was an alternative to implement clickable drop down menus without Javascript. The simple event processing these menus generally require could probably be handled by a very limited subset of Javascript. Perhaps some declarative event handling could be defined such as click or gesture state that feeds into the CSS calculations, for example: clicks cycling a property through a numerical sequences, [0 and 1 to toggle a pull down menu, 0 to 3 for 90 image rotations in a gallery etc.], separate left and right rotation buttons could be implemented by subtracting one button counter from another in CSS calculations. cheers Fred
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
> Date: Wed, 29 Aug 2012 10:52:05 -0400 > From: bzbar...@mit.edu ... > On 8/29/12 10:15 AM, Fred Andrews wrote: > > Yes, but fluid layout could use some calculations and is it likely that > > declarative calculations would ever be added to CSS? > > You mean other than http://dev.w3.org/csswg/css3-values/#calc ? Sorry I was not even aware of this, and thank you for pointing it out. Yes, I think this is a good direction. With some extensions to this feature perhaps image sets would become unnecessary. The CSS calculations could just enable the appropriate image based on the image box pixels size, and it would have a lot more flexibility than the image set proposals. It could also be used to select among video sets. Perhaps also among stereoscopic 3D image formats if this were an attribute available to the calculations. cheers Fred
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
> From: bhawkesle...@googlemail.com > Date: Wed, 29 Aug 2012 08:34:47 +0100 ... > > Javascript is just too general a programming language for easy management > > and is heading in the direction of Java. > > I'm not sure how far the problem is Javascript, rather than the > browser and document object models exposed to JS. HTML does now offer > improved sandboxing (see the sandbox attribute on iframe). But see > also http://www.adsafe.org/ for some more ideas about sandboxing JS. Interesting perspective, thanks. The privacy of a mashup seems easier to solve as it need not modify the source document and could just sandbox the source websites leaving them unmodified and consuming the content to build a new page to present. Some of the iframe extensions go some way to solving the privacy of mashups and I see a path to improving it further. Access to the DOM does cause a big privacy leakage. Some popular privacy and safety add-ons for Firefox modify the DOM and even place their UI within the DOM making their presence and some of their state visible to websites. For example Ghostery seems to do this and this appears to allow a website to detect the add-on and even to see the list of blocked sites. The Ghostery UI should be moved to the Chrome context, but some of these add-ons still need to modify the document and while these modifications are visible there remains privacy leakage. Can a solution be found to make the operation of these add-ons a private matter? A path to protecting the privacy of webpage modifications that are applied by privacy and safety add-ons is not clear. I've not been able to think up an approach that can not be subverted. The solution would seem to require the language to not have the capability to reflect on its own code and to not be able to implement its own language that it can observe, and this would seem to preclude Javascript. Perhaps this is not a problem that can be solved, and perhaps privacy and safety will need to be addressed in other ways rather than hacking on the document Javascript. Perhaps reducing the opportunities for fingerprinting and storing state would go some way to limiting unwanted tracking and I am look at ways that iframe extensions could assist this. > > For example a lot could be done with data-flow computations. > > Are you talking about something like the "calculate" property from XForms? I had declarative data-flow languages in mind. Something that could handle simple event processing such as drop down menus and calculations for fluid website designs. This could just be a limited subset of Javascript. There may be some utility in working out a subset of Javascript that preserves privacy - this could give another option between enabling and disabling JS and some websites could likely work within this, certainly a larger subset than those that work without JS. > > This could implement equations for layout, > > Layout deficiencies are best addressed by adding CSS features, no? Yes, but fluid layout could use some calculations and is it likely that declarative calculations would ever be added to CSS? cheers Fred
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
> Date: Tue, 28 Aug 2012 21:41:02 + > From: i...@hixie.ch > To: callow_m...@hicorp.co.jp > CC: wha...@whatwg.org > Subject: Re: [whatwg] Why won't you let us make our own HTML5 browsers? > > On Fri, 8 Jun 2012, Mark Callow wrote: > > On 08/06/2012 06:09, Ian Hickson wrote: > > > The dire warning doesn't work. I'm just saying that's the direction > > > that operating system vendors have been going in; that disallowing it > > > in the browser case is not a different direction, it's consistent with > > > the industry's direction as a whole. > > > > The platform providers want control so they can extract money from > > application developers; they do it under the guise of safety & security > > so people will go along with it. Governments get control over people in > > the same way. > > > > In both cases it is an existential threat to freedom and civil > > liberties. > > If one works from these assumptions, why would we assume that it is > nonetheless possible for us to specify something that works against these > motivations? Putting something in the spec doesn't magically make it > appear in browsers. Some statements in the spec could help defend privacy and freedom even if these are only implemented in a limited number of browser or even only as add-ons. Some examples: 'The user-agent is not intended to accurately identify the browser and is user selectable and could well be set to a known common browser user-agent string to help preserve user privacy and prevent fingerprinting. Further using a trademark in a user-agent gives everyone the right to use the trademark within their user-agent.' If this language is not acceptable then we just need to remove the user-agent from the spec. 'Web browser clients may well be implemented 'in the cloud' as a service, and this could well mean that an IP address does not correspond to a user but rather the cloud service host.' [Defend Opera Mini and other innovations] 'The execution of Javascript in the browser and thus the interpretation of any algorithms are at the discretion of the user. The user may disable Javascript or modify the interpretation of Javascript code to suit their consumption and may use proxies to answer or filter communication from the browser. Specifically the web browser platform is not intended for the implementation of any effective DRM measures.' 'Javascript is delivered in source form so it is not intended to provide protection from being disassembled. Since browsers interpret Javascript as a natural part of presenting content and since they may well need to understand the code to implement control mechanisms it is specially not intended to provide protection from reverse engineering.' 'The presentation of web content is at the discretion of the user and their browser may selectively present content, transform the content, or augment the content as part of the private consumption and presentation process.' 'For example a cloud service many implement a browser that presents only the audio from videos.' [Google seem to have already taken down some such sites] 'A web browser may well be implemented as distributed services, transforming and caching content for consumption at a time and place chosen by the user. For example a 'cloud browser' may transform a website video and deliver it to a remote mobile device for presentation at a later time.' 'The manner in which a web browser presents content or interprets Javascript are a private matter of the user and the web browser may well implement measures to maintain privacy and block any attempts to detect the presentation and consumption methods.' This approach could be continued to all browser privacy and freedom matters. Those that want to turn the browser platform into a managed content consumption and spyware platform should just take their project elsewhere and start their own new platform. We should also consider new computation approaches for use within web content that gives the users better control. Javascript is just too general a programming language for easy management and is heading in the direction of Java. For example a lot could be done with data-flow computations.This could implement equations for layout, and simple event processing, that would meet the needs of many websites without the need to even enable 'Javascript'. More advanced data-flow blocks could well be managed by the user, much like apps, and may run managed Javascript. General Javascript code execution needs to be separated from the web content - the two have become confused. cheers Fred
Re: [whatwg] img srcset / css image-set issues
... > But that's exactly my point! The w/h descriptors are sufficient *only* for > art direction, where you want to swap between completely different images > (or at least different crops of the same image), based on viewport size, to > match other changes occurring in your responsive design as the viewport > size changes (and they do a fine job at art direction). > > They are *not* suitable (even combined with x descriptors) as a general > purpose mechanism for dealing with flexibly-sized images, where you need to > match the number of device pixels taken up by the image to the number of > image pixels in the image you load (while allowing the browser to adjust > this based on bandwidth constraints etc), since doing that properly > *requires* additional information, i.e. knowing the intrinsic size (or at > least intrinsic width or height) of the image before choosing which to > download. Agreed. The width and height of the images is what is needed. The browser needs to fill pixels so needs to know the sizes of the available images in pixels. Forget the x scale descriptions and all the other proposed extensions and just include a set of images with their pixel height and width. Forget dpi etc, its just not needed for this. Consider adding a 'selected' flag to give JS control of the selection. If a particular image is 'selected' then it is the default choice. If no image is 'selected' then the browser can use a default algorithm to make a choice based on the target image box size and user choices relating to image quality versus bandwidth tradeoffs. This allows JS to override the browser default algorithm. For example a web gallery can offer visitors a 'quality' choice and use this to flag an appropriate selected image. Image cropping and centering is something best left to JS algorithms. Fluid cropping and centering may need an algorithm that takes into account particular areas of interest and focus within an image, and user choices which would be better handled within the webpage and not at the browser level. A web gallery may allow visitors to choose to scale versus crop images and to pan cropped image. The fact that many people disable JS because they feel it is abused is a fault in the design and should be corrected elsewhere - simple data-flow calculations could handle many of these algorithms safely and still give people confidence to enable them. Regarding bandwidth choices, is there are proposal that the image sizes in bytes could be declared in the HTML, or is there an expectation that the browser will query the server for the size of each image, or would web browser just use a heuristic to estimate the image byte size scaling based on the image dimensions? ... > No, it's not fine to just toss in an additional breakpoint. If you do this > for all important device categories you go back to the monstrous 16-entry > srcset I showed earlier, which is clearly unsustainable. Agreed. MQs do not map well to the task. The image box size is not just a matter of the media, but depends on the scaled image box size on the webpage. > The art direction use case can be entirely orthogonal. It should be handled > with the w/h descriptors as currently specified. What I'm proposing would > operate after any w/h descriptors have narrowed down the set of allowable > images, and let the browser choose between the remaining images more > intelligently in the case of flexible-size images, where currently the > browser has no idea which to use. Yes, this sounds like a better approach. It there are proposal taking this view into account? cheers Fred
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Tue, 19 Jun 2012 11:56:04 +0200, Chaals McCathieNevile
wrote:
> On Fri, 08 Jun 2012 05:05:11 +0200, Mark Callow
> wrote:
>
>> On 08/06/2012 06:09, Ian Hickson wrote:
>>> The dire warning doesn't work. I'm just saying that's the direction that
>>> operating system vendors have been going in; that disallowing it in the
>>> browser case is not a different direction, it's consistent with the
>>> industry's direction as a whole.
>> The platform providers want control so they can extract money from
>> application developers;
>
> Sure. Although in most cases they are not in a position to enforce this.
> You *can* choose another browser - or even make your own. If you don't,
> then you're failing to keep your side of the freedom bargain ("the price
> of freedom is eternal vigilance")
>
>> they do it under the guise of safety & security so people will go along
>> with it. Governments get control over people in the same way.
>
> The comment is sometimes true. It is also true that users get very upset
> *at the browser* when it permits things to happen that they hadn't
> expected. The same-origin security policy that is rampant on the Web is
> clearly unhelpful in many ways. And doesn't have any particular benefit
> for browser manufacturers, except that it protects users.
>
>> In both cases it is an existential threat to freedom and civil liberties.
>
> I think that is overstating the case. A *lot*. Nobody forces you to follow
> the way this is specified. You can just implement something different, and
> nobody will stop you. That happens all the time, for different issues. It
> is simply untrue to say that nobody will *let* you make your own browser.
> We write the spec so you can more easily figure out how to make it
> compatible with the web - in other words, to *help* you do so.
I wish this were the case, however it does appear that websites,
are trying to control the platform. They do this via their terms
of use and by twisting laws to suit them. There was a recent case
in which Google took down a website that presented audio from
youtube videos, stating terms of use violations and copyright laws.
This service could well be viewed as a cloud web browser that was
presenting the content in a format requested by the users. There
are many other terms of use that attempt to place significant
restrictions on use. If it can ever be claimed that HTML is a
standard suited to delivery of digital content on the terms stated
by websites then it will be a significant loss.
Adding virtual browser app support would make it so easy to develop
and share customized web browsers that it would be near
impossible for websites to enforce restrictions.
It would also empower users of devices with a fixed browser to
still be able to have a web app that suits their needs. It is
very easy for devices to lock out other native browsers, but if
custom browsers apps become popular then such devices would be
less attractive which would place pressure on them to open up.
The browser app need not have any more privilege than any other
webpage. It can manage its own navigation tabs and history. It
could even be of utility if it was unable to save files. For
example, a browser app could implement privacy strategies to
minimize fingerprinting and tracking etc.
The Firefox OS project is developing an implementation and I
think this is a really exciting development that could empower
web users. It would help web users use their browser in the
manner they want rather than as dictated by websites.
I will try to assist the development of this feature and to make
an implementation available as a modification to Firefox if it
does not get official support in Firefox.
There are some real concerns relating to the trust users place in
the browser apps. However these apps could be curated as for
current add-ons.
cheers
Fred
