Re: [whatwg] A mask= advisory flag for link rel=icon
We're considering supporting SVG in the places in the UI where we render the icon in full color. Nothing to announce currently. - Maciej On Jun 24, 2015, at 8:33 PM, Kevin Marks kevinma...@gmail.com wrote: Does this mean we can now have rel=icon with SVG instead of providing a bitmap for every iOS device specifically (when we add to homepage)? Do chrome and Firefox support SVG icon images? On 24 Jun 2015 2:40 pm, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak m...@apple.com wrote: To close the loop on this, we will change to link rel=mask-icon href=whatever.svg color=#aabbcc. We like the idea of determining the color from the SVG, but we won't be able to implement in time for this cycle, and having an explicit color override seems useful. So for now we'll implement explicit color and we'll consider automatic color picking based on the SVG as a fallback when the color is missing as a future extension. Please let me know if anyone disagrees with this approach. Sounds acceptable to me. What's the grammar of color=''? Just hex, or full CSS color? (Either is fine with me.) ~TJ
Re: [whatwg] A mask= advisory flag for link rel=icon
To close the loop on this, we will change to link rel=mask-icon href=whatever.svg color=#aabbcc. We like the idea of determining the color from the SVG, but we won't be able to implement in time for this cycle, and having an explicit color override seems useful. So for now we'll implement explicit color and we'll consider automatic color picking based on the SVG as a fallback when the color is missing as a future extension. Please let me know if anyone disagrees with this approach. Regards, Maciej On Jun 17, 2015, at 3:32 PM, Maciej Stachowiak m...@apple.com wrote: Out of curiosity, I understand that flat design is fashionable right now and you might want single colour icons to represent web sites in Safari, but what is your fallback for the billion or so web sites which currently only provide a multi-coloured icon? I assume you just display the icon they provide? Details of the UI of the pinned tabs feature are a bit out of scope for this mailing list, but since it might provide useful context to people, here are some facts: - We sometimes display the mask icon in the specified color, and sometimes in a medium grey. - We I meant to say - If no mask icon is provided, we will fall back to a monochrome monogram for the site rather than the full-color icon, in the context where mask icons are currently used. Regards, Maciej
Re: [whatwg] A mask= advisory flag for link rel=icon
On Jun 17, 2015, at 12:42 PM, Benjamin Francis bfran...@mozilla.com wrote: On 17 June 2015 at 20:23, Maciej Stachowiak m...@apple.com wrote: Using a mask attribute in place of href would solve the compat problem about as well as using rel=“mask-icon”, but it seems kind of weird to me. It doesn’t make sense for an icon link to have both a mask and an href. It makes sense to me, an image element can have a src attribute of image.jpg and have a mask set to mask.svg in the mask CSS property [1]. The equivalents here are the href attribute and the mask attribute, It's just that in your case you want to specify a solid colour to mask instead of an image, so you would omit the href attribute. That makes sense in theory, but I don’t think anyone intends to support combining a full-color image with a mask, so this implies a level of generality that the feature won’t actually have. Also, I don’t think there is any use case for supplying both an image and a mask. Since the site icon can itself have an alpha channel, you could always pre-mask it. And it’s not really a consideration that you’d want to post-process an existing image. Based on that, I think it’s better to use a separate link type rather than to act as if an icon link could have two URLs. - Maciej That said, I'm not opposed to the creation of a new link relation with option A.2 if that's what people would prefer. Ben 1. https://developer.mozilla.org/en-US/docs/Web/CSS/mask
Re: [whatwg] A mask= advisory flag for link rel=icon
Out of curiosity, I understand that flat design is fashionable right now and you might want single colour icons to represent web sites in Safari, but what is your fallback for the billion or so web sites which currently only provide a multi-coloured icon? I assume you just display the icon they provide? Details of the UI of the pinned tabs feature are a bit out of scope for this mailing list, but since it might provide useful context to people, here are some facts: - We sometimes display the mask icon in the specified color, and sometimes in a medium grey. - We I meant to say - If no mask icon is provided, we will fall back to a monochrome monogram for the site rather than the full-color icon, in the context where mask icons are currently used. Regards, Maciej
Re: [whatwg] Icon mask and theme color
Consolidating replies to limit spam. On Jun 16, 2015, at 4:37 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Maciej Stachowiak m...@apple.com writes: […] Where do we go from here: (1) We could add mask or something like it to the standard, and change browsers to ignore mask icons in contexts where they are looking for a regular icon. (2) We could change to a new rel type for mask icons, such as rel=mask-icon, but keep theme-color as the source of the color, with the possibility of darkening light colors used to make light colors viable. (3) We could change to a new rel type for mask icons, such as rel=mask-icon, and give it a color attribute to be used specifically for the icon. […] (4) Set a MIME type like application/vnd.apple.svg-mask+xml. This might prevent breakage in other browsers and allow opt-in without introducing new attributes. The source of the theme color could then be in the file or in the theme color meta value. I think inventing a new MIME type or a new file format would be less elegant than a new rel value, and it would be harder for authors to adopt correctly, so I think this is dominated by (2)/(3). At least, I can’t think of a way in which it would be better. (5) Use the shape of the path in the SVG icon as a mask and retain the theme color meta value. Why isn't this done? One could have a properly colored icon for one purpose and use the outline of the same icon for the flat design staff. We could change to considering only the alpha channel of the mask icon instead of both mask and luminance. We did it this way because we already had code to treat SVG as a mask for the mask, and it seemed better to be consistent. Note though, that even if we went alpha-only, it might not be possible to use the same file for a mask icon and a full-color icon and get good results, for certain effects. I believe others on the thread have explained this already, but another obvious example is Facebook’s normal favicon, which is a white lowercase f on a blue rounded rectangle. It’s important in the color version for the white to be white, not transparent, but if both the white and blue are solid, the mask version is just a roundrect. On Jun 16, 2015, at 1:48 PM, Ben Francis bfran...@mozilla.com wrote: On Mon, Jun 15, 2015 at 8:00 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: First: it looks like we neglected to send our proposal for this ahead of our preview release. It’s now been sent belatedly. We regret the error. Second: we’re definitely open to changing this if there’s consensus for a different syntax. Just putting this out there, did you consider using the W3C web manifest [1] for the pinned sites feature? We looked at it, but we didn’t want to require a whole new format for the feature to work at all. I wouldn’t rule out using it in the future as a possible alternate source of metadata for pinned tabs (or for websites saved to the home screen on iOS), but I can’t make any commitments on this. In any case, web manifest would still require us to figure out a way to specify mask icons, and source of color for the mask icon. […] We are still discussing the properties of an icon object in that spec and it already has a background_color member. We could explore adding something there that fits Apple's requirements? Perhaps this could be used to deprecate the proprietary apple-touch-icon as well? If that sounds interesting to you then please feel free to file an issue on GitHub https://github.com/w3c/manifest/issues https://github.com/w3c/manifest/issues The color for the mask icon is a foreground color, not a background color. I’m not yet sure whether it mask icons need a dedicated color or could just use the theme color. On Jun 15, 2015, at 12:53 PM, Kornel Lesiński kor...@geekhood.net wrote: Another suggestion: (4) Don't require the mask icon to be 100% black and read the color from the icon itself. The mask flag would indicate that shape of the icon is distinctive enough, i.e. alpha channel of the icon can be used without the color channels, but wouldn't forbid use of color channels. If in Safari you'd like to enforce use of only a single solid theme color for the icon, then you can compute the theme color by averaging colors of all non-transparent pixels of the mask icon, and use that as the icon's theme color. We do have a requirement to have the mask icons render with a single color. I don’t think the approach suggested here is very good. Color averaging would not be very predictable in its results and could be unstable to changes in the icon if it’s actually multi-color. One thing we could do is move the color specification from the webpage to a meta tag inside the SVG or something, but I’m not sure that’s a huge improvement either. Regards, Maciej
Re: [whatwg] A mask= advisory flag for link rel=icon
On Jun 16, 2015, at 9:49 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Before we start bikeshedding, can you commit to actually changing your implementation? Safari has already shipped with the exact proposal given in this thread; if you're seeking a rubberstamp rather than a collab, say so. Maciej already clarified this, no? They're perfectly happy to change this before Safari 9 ships, provided, I'm guessing, that we settle this somewhat quickly. Yep. Quoting myself from earlier: On Jun 15, 2015, at 12:00 PM, Maciej Stachowiak m...@apple.com wrote: We don’t have a strong principle on this, and it’s not too late to change before shipping the release version of Safari 9. We welcome input on which of these would be best, or whether something else entirely is better. To be even more explicit, we’re willing to change. If there’s a rough consensus soon, we can change it before any final non-beta release of Safari ships with the feature. Even if the discussion continues for a while, we may be able to change after we ship, but we might have to stage it and support two syntaxes for a while. It seems like the current leading candidate is: - Change link rel=icon mask to link rel=mask-icon, but keep using the theme-color meta for the color If anyone feels strongly about sticking with the icon rel value, please speak up. It might also be good to change interpretation of the icon as a mask to consider only alpha. But this probably wouldn’t affect the spec since how any link rel=icon is rendered is implementation-specific. Also, t would not make it practical to use the same icon for mask and non-mask purposes in most cases, so it wouldn’t help with the compat issue. So this aspect seems less urgent. Regards, Maciej
Re: [whatwg] A mask= advisory flag for link rel=icon
On Jun 15, 2015, at 5:40 PM, Justin Dolske dol...@mozilla.com wrote: Hmm, I suppose Elliott's proposal is a bit ambiguous, but I read it as fixing the ordering issue by adding a separate mask rel value. Such that the following are equivalent and independent of ordering: A) link rel=icon href=colorful.pnglink rel=mask href=black.svg B) link rel=mask href=black.svglink rel=icon href=colorful.png And if someone actually did want the same icon for both, they could do: C) link rel=icon mask href=blackhole.svg That isn’t how I interpreted Elliot’s proposal. That said, if we do make a new standalone rel value for mask icons, I would suggest mask-icon or something like that instead of mask, since mask is too generic a term. - Maciej Justin On Mon, Jun 15, 2015 at 4:20 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 15, 2015, at 3:55 PM, Elliott Sprehn espr...@chromium.org wrote: Adding a whole new attribute for this seems like overkill, why not use the rel. link rel=icon mask href=... sizes=... That's what the rel list was designed for. In general, rel values are supposed to be orthogonal, they should not modify each other’s meanings. rel=“alternate stylesheet” and rel=“shortcut icon” are two specific historical exceptions. But rel=“license help” means the link is both the license and the help for the page, not that it’s help about the license or anything like that. So I don’t think it would be a good pattern to use the rel value for this. It also wouldn’t solve the immediate problem with browsers getting the wrong icon because sites didn’t carefully set the correct order. Perhaps we don’t care about solving that, but if so, I’m not sure it’s an improvement. - Maciej On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com wrote: When link is used to pull in external resources, authors may use several attributes as hints about the linked resource to help UAs decide whether or not to load it. ... This combines well with the other resource hints we already have: link rel=icon href=mask.svg type=image/svg+xml sizes=any mask There are any number of properties UAs might want to use when deciding whether or not to load a resource, so you might think we shouldn't add a new, one-off attribute every time we identify one. Instead, we could add a generic hints attribute and have it take a space-separated list of advisory info about the resource. That space separated list already exists, it's called rel. - E
Re: [whatwg] A mask= advisory flag for link rel=icon
There’s no technological enforcement that the SVG only uses the color black. We will interpret it as a mask in the same way as the SVG ‘mask’ element, which effectively combines the luminance with the alpha channel. Effectively, this means that other colors will end up partly transparent, so using other colors will probably do something weird, but nothing prevents authors from doing that afaik. The reason for treating the icon as a mask is that we want to enforce having a monochrome shape, specifically for our pinned tabs feature. Regards, Maciej On Jun 15, 2015, at 6:52 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: If I am not mistaken, it should be possible to use the outline shape while not requiring 100% black color for every path in the SVG icon. As I see it, a proper icon has to have a distinctive outline anyway. Karl Dubost k...@la-grange.net writes: Nils, Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net a écrit : Edward O'Connor eocon...@apple.com writes: These images can be tinted to better fit in with the site's theme. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. Ed, maybe, replied already I believed in the sentence above. The mask icon is giving just a shape. So that the chosen theme of the phone can customized the color to its own choice. Be imposed by the brand of the operator, or I guess someone hacking its theme to have its own. see for example http://stackoverflow.com/questions/9711481/icon-color-on-different-themes I guess things like Android theme, icon sets, etc. would give some answers. https://dribbble.com/search?q=+icon+sets+monochrome It's a way for a site to provide a generic shaped icon but that will adjust its colors depending on the theme. -- Karl Dubost http://www.la-grange.net/karl/ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Icon mask and theme color
On Jun 15, 2015, at 3:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński kor...@geekhood.net wrote: The new Safari is still only a preview, so I hope Apple will switch to a better solution. It would be great if we could get some feedback from Ted colleagues on what the thinking here was. First: it looks like we neglected to send our proposal for this ahead of our preview release. It’s now been sent belatedly. We regret the error. Second: we’re definitely open to changing this if there’s consensus for a different syntax. Our original thinking on this: rel=icon is intended to support selection from multiple formats and sizes. It seemed natural to extend this to the notion of a monochrome icon that’s intended to be recolored. Before deploying the feature, we thought it would be cleaner to extend rel=icon than to invent a new rel value. (There’s already the legacy -apple-touch-icon value with in theory could be obsoleted by rel=icon with the appropriate size). For similar reasons, it seemed better to reuse the existing theme-color meta (which gives license to darken or lighten the color as needed). The nature of the problem: to avoid breaking the regular favicon, both in Safari and in other browsers, sites need to make their regular favicon explicit with a rel=icon link (instead of relying on favicon.ico), and need to put the mask icon first instead of last in the list of icon links. We thought clear advice to do this, plus the fact that breakage should be obvious, would limit the scope of the error and would lead sites to fix it promptly. That doesn’t seem to be happening, at least yet. We noticed this problem internally even before shipping (working with some sites to get mask icons up before release), but there was internal debate about whether the problem would shrink or grow over time. Where do we go from here: (1) We could add mask or something like it to the standard, and change browsers to ignore mask icons in contexts where they are looking for a regular icon. (2) We could change to a new rel type for mask icons, such as rel=mask-icon, but keep theme-color as the source of the color, with the possibility of darkening light colors used to make light colors viable. (3) We could change to a new rel type for mask icons, such as rel=mask-icon, and give it a color attribute to be used specifically for the icon. We don’t have a strong principle on this, and it’s not too late to change before shipping the release version of Safari 9. We welcome input on which of these would be best, or whether something else entirely is better. Sorry again for not bringing this up before the preview release that included this feature. Regards, Maciej
Re: [whatwg] A mask= advisory flag for link rel=icon
On Jun 15, 2015, at 3:55 PM, Elliott Sprehn espr...@chromium.org wrote: Adding a whole new attribute for this seems like overkill, why not use the rel. link rel=icon mask href=... sizes=... That's what the rel list was designed for. In general, rel values are supposed to be orthogonal, they should not modify each other’s meanings. rel=“alternate stylesheet” and rel=“shortcut icon” are two specific historical exceptions. But rel=“license help” means the link is both the license and the help for the page, not that it’s help about the license or anything like that. So I don’t think it would be a good pattern to use the rel value for this. It also wouldn’t solve the immediate problem with browsers getting the wrong icon because sites didn’t carefully set the correct order. Perhaps we don’t care about solving that, but if so, I’m not sure it’s an improvement. - Maciej On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com wrote: When link is used to pull in external resources, authors may use several attributes as hints about the linked resource to help UAs decide whether or not to load it. ... This combines well with the other resource hints we already have: link rel=icon href=mask.svg type=image/svg+xml sizes=any mask There are any number of properties UAs might want to use when deciding whether or not to load a resource, so you might think we shouldn't add a new, one-off attribute every time we identify one. Instead, we could add a generic hints attribute and have it take a space-separated list of advisory info about the resource. That space separated list already exists, it's called rel. - E
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Feb 20, 2014, at 9:01 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/20/14 11:18 AM, Tab Atkins Jr. wrote: (If people used rAF for what it was *intended* for, we could probably have stopped firing it *entirely* when the window isn't visible. We do. At least Chrome and Firefox do. Safari too. Instead, we had to compromise with the 1s refresh rate instead.) That's what Chrome and Firefox do for setTimeout/setInterval. We actually clamp timers even more for background tabs if the page has not done anything externally observable (e.g. Send or receive network data) in a while. Cheers, Maciej
Re: [whatwg] Simplified picture element draft
On Dec 31, 2013, at 7:17 AM, Yoav Weiss y...@yoav.ws wrote: On Mon, Nov 25, 2013 at 5:33 PM, Adam Barth w...@adambarth.com wrote: Is there an editor's draft or some other relatively self-contained write-up that I could review? Tab has rewritten the picture spec to match the latest proposal. You could review it at http://picture.responsiveimages.org/ This approach seems cleaner than src-n. I'll try to read it in more detail, but a few initial comments: - Is there any reason not to allow the sizes= attribute and the extended definition of srcset= on img as well as source? It seems like the picture wrapper is not helpful in cases where you only use one source element. - It seems this draft allows arbitrary media queries, with only a subset expected to give best performance (by correctly informing the preload scanner). In my opinion, this is worse than the alternative of only supporting the media queries that could plausibly be integrated with preload scanning. Creating a programming interface with a performance cliff - a point beyond which performance suddenly gets significantly worse for what seems like a small incremental change - is generally a bad idea. And the use cases for fully general media queries seem much more speculative than the ones for the simplified subset. Regards, Maciej
Re: [whatwg] Add input Switch Type
On Nov 19, 2013, at 1:37 AM, Jonas Sicking jo...@sicking.cc wrote:
Realistically speaking, I don't think this will help much at all. Few
websites like using the default styling for form controls anyway and
so people would be just as unhappy with the default switch rendering
as they are with the default checkbox rendering.
Default-styled checkboxes seem to be somewhat more common than default-styled
buttons. We also get requests for an easy way to get a switch that uses the
native iOS look from time to time, from authors who don't want to replicate the
artwork and interactive behavior by hand.
In my opinion, figuring out general styling for all form controls is very
useful, but an appearance value to provide a standard switch look and behavior
would also be useful.
Regards,
Maciej
The real fix is to allow styling formcontrols. It's one of the most
requested features from web developers, yet no one has taken the time
to research what it would take to do it.
I'm quite sure that if someone comes up with a comprehensive and well
researched proposal, that browsers would jump on it.
And the fact that we now have shadow DOM defined should help a whole lot.
/ Jonas
On Tue, Nov 19, 2013 at 1:04 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
Brian M. Blakely, 2013-09-21 02:03 (Europe/Helsinki):
I was contemplating whether to propose a new input type, or an
attribute valid only for checkboxes. But it isn't a checkbox, so I
went with a new type value. You can choose to slide the switch or
click it in most OS implementations, so even the behavior is
different from a checkbox.
I agree that the look and feel is different from checkbox but all the
differences seem to be purely presentational. If you disagree, you need to
elaborate a bit more.
I'd suggest pursuing something along the lines
input[type=checkbox].switch
{
appearance: lightswitch;
}
instead. That way you could use CSS media queries and use lightswitch
appearance for narrow viewports and regular checkboxes for wider viewports.
However, if you're requesting for more featured switch seen in e.g. newer
Android applications where the switch has embedded text labels to declare
the switch positions, there might be need for a new markup.
An example of such UI in ASCII graphics:
++---+
| 蚓 |== 蚌 =| Temperature unit
++---+
(That is, a label Temperature unit with a switch with labels degree
Celcius and degree Fahrenheit. In the real UI the label is on the left
and switch is aligned to right margin but I put it this way to have a
slightly better change for ASCII graphics to work correctly.)
I personally hate this UI and would much prefer using two radio buttons for
this. Still, this is a native UI concept on this platform and I see no
reasonable way to convert a real HTML radio button group into this using
just CSS. The closest thing is allowing to allow rendering a select
element with just options with a lightswitch appearance.
--
Mikko
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 19, 2013, at 4:17 PM, Laurent Perez l.lauren...@gmail.com wrote:
Hi
I was at the Paris RICG meetup in Paris, I understand the complexity of the
responsive requirements.
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
img src= class=artdirection/
What do you think ?
We've been discussing these kinds of CSS-based proposals. Is there a reason you
picked 'background-image' instead of 'content'? As discussed earlier in the
thread 'content is likely to work better in a variety of ways.
Also, what do you think about the attr(src-medium url) trick, which would let
the image URLs be in the markup but the media queries in un-repeated CSS?
Regards,
Maciej
laurent
On Tue, Nov 19, 2013 at 2:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
I see. It seems like it would be simpler to just define content on a
real element to have the existing WK/Blink behavior without saying
replaced. It is not obvious why ignoring the element size is a useful
default behavior. But I suppose that discussion is out of scope here and
would better be discussed in a CSS-relevant forum.
Yeah, feel free to raise it in www-style if you're interested.
Otherwise, fantasai and/or I will take care of it in due time, when we
have time for it.
For the sake of curiosity: is there any reasonably accurate current
draft that describes what 'content' is supposed to do on a non-pseudo
element?
Nope.
The most recent reference I could find is
http://www.w3.org/TR/css3-content/ but that hasn't been updated in a
while. It says If the computed value of the part of the 'content' property
that ends up being used is a single URI, then the element or pseudo-element
is a replaced element. The box model defines different rules for the layout
of replaced elements than normal elements. Replaced elements do not have
'::before' and '::after' pseudo-elements; the 'content' property in the
case of replaced content replaces the entire contents of the element's
box. But I can't tell if that matches what you say or is the opposite.
Right, Content is out-of-date and hasn't been sanity checked. Don't
let the recent-ish date fool you; it's just a stripped-down version of
the older 2003 draft, and the remaining parts haven't been seriously
gone over yet.
~TJ
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 18, 2013, at 9:05 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote:
It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
This will never work; for legacy compat reasons, url() is not a
function, but a syntax construct specially recognized and handled by
the parser. (Don't nest incompatible microsyntaxes, kids!)
url(attr()) is compatibly a bad-url token right now.
However, attr(foo url) does work, at least per spec. I don't think
it's been implemented yet.
Thanks for the clarification. Modulo the syntax change, it still seems like
something eminently implementable.
- For Safari and Chrome, content: replaced url() doesn't work. I couldn't
find a spec for the 'content' property that includes the 'replaced' token so
I am not sure what it is even supposed to do.
Yes, this has been a longstanding suggestion to make a 'content' image
actually make the image replaced, as opposed to its current behavior
which inserts an anonymous replaced-element child into it. As
fantasai and I haven't significantly picked up the Content spec
lately, we haven't added it yet.
I'm not enough of a CSS expert to understand the implications of that change.
What would be the observable behavior changes that 'content: replaced' would
produce?
- For Firefox, the 'content' property doesn't work on an element (as opposed
to :before and :after)..
This is just a lack of implementation.
I was able to get Safari and Chrome to work by getting rid of 'replaced' and
specifying the images in CSS instead of using url(attr). With those changes,
I noted the following possibly undesirable effects:
It didn't actually work - if you try to size the element, you'll note
that the images don't care.
Not sure what you mean by this. Do you mean that explicitly sizing the img
will be ignored by the replaced 'content' image? Because that does not seem to
be Safari or Chrome's current behavior. In particular, this markup always gives
me a 10x10 image but the contents change with the window size:
style
.artdirected {
width: 10px;
height: 10px;
}
@media (min-width: 480px) {
.artdirected { content: url(foo-small.jpg); }
}
@media (min-width: 600px) {
.artdirected { content: url(foo-medium.jpg); }
}
@media (min-width: 800px) {
.artdirected { content: url(foo-big.jpg); }
}
/style
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
(1) Saving the image from the context menu (or opening in a new tab or
window, or other context menu operations like copy) always uses the src
image instead of the selected image. Dragging it uses the correct image.
Sounds like something that could potentially be fixed.
(2) Preloading will always preload the src (and I suspect the normal loader
would do it to so that both the image src and the content: replaced source
will be loaded).
This is because the preloader doesn't understand CSS yet.
Yes, but this affects (a) polyfill deployability and (b) the level of
cleverness required in the preloader's CSS parsing (it has to not only start
preloads from CSS but inhibit natural image preloads).
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 18, 2013, at 2:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak m...@apple.com wrote:
I'm not enough of a CSS expert to understand the implications of that
change. What would be the observable behavior changes that 'content:
replaced' would produce?
- For Firefox, the 'content' property doesn't work on an element (as
opposed to :before and :after)..
This is just a lack of implementation.
I was able to get Safari and Chrome to work by getting rid of 'replaced'
and specifying the images in CSS instead of using url(attr). With those
changes, I noted the following possibly undesirable effects:
It didn't actually work - if you try to size the element, you'll note
that the images don't care.
Not sure what you mean by this. Do you mean that explicitly sizing the img
will be ignored by the replaced 'content' image? Because that does not seem
to be Safari or Chrome's current behavior. In particular, this markup always
gives me a 10x10 image but the contents change with the window size:
Ah, right, WK/Blink violate the spec wrt 'content' on real elements.
They don't support the normal value set, but do support a single
url(), which makes the element replaced.
Try it on a ::before pseudo, which implements the actual spec for 'content':
!DOCTYPE html
div/div
style
div::before {
display: block;
width: 400px;
height: 100px;
border: thin solid;
content: foo url(http://xanthir.com/pony);
}
/style
Even if you remove the foo string, so it's just a single image, it
still just sits there in the pseudo-element at its normal size,
ignoring the div::before's size entirely.
The replaced keyword will be a new branch in the 'content' grammar,
which allows a single url() after it, and does what WK/Blink currently
do.
I see. It seems like it would be simpler to just define content on a real
element to have the existing WK/Blink behavior without saying replaced. It is
not obvious why ignoring the element size is a useful default behavior. But I
suppose that discussion is out of scope here and would better be discussed in a
CSS-relevant forum.
For the sake of curiosity: is there any reasonably accurate current draft that
describes what 'content' is supposed to do on a non-pseudo element?
The most recent reference I could find is http://www.w3.org/TR/css3-content/
but that hasn't been updated in a while. It says If the computed value of the
part of the 'content' property that ends up being used is a single URI, then
the element or pseudo-element is a replaced element. The box model defines
different rules for the layout of replaced elements than normal elements.
Replaced elements do not have '::before' and '::after' pseudo-elements; the
'content' property in the case of replaced content replaces the entire contents
of the element's box. But I can't tell if that matches what you say or is the
opposite.
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, 2013, at 9:00 AM, Yoav Weiss y...@yoav.ws wrote:
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com wrote:
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
You're right, Maciej's concerns were addressed by Christian's proposal (and
John's followup proposal).
Any thoughts on my concerns with making inline CSS mandatory (especially
from the CSP angle)?
To be clear, I really like the idea of a style-based responsive image solution,
as it involves significantly less additional syntax and may avoid some
repetition. I just want to make sure whatever we come up with does not have any
undesirable side effects.
I can't get this particular example to work in Safari, Chrome or Firefox. Is it
meant to? It seems to always show foo.jpg. Here's a worked version with
distinct images for each filename:
The reason I tried is because I want to see what side effects this approach
might have without having to guess that from the specs.
It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
- For Safari and Chrome, content: replaced url() doesn't work. I couldn't find
a spec for the 'content' property that includes the 'replaced' token so I am
not sure what it is even supposed to do.
- For Firefox, the 'content' property doesn't work on an element (as opposed to
:before and :after)..
I did not get a chance to test IE.
I was able to get Safari and Chrome to work by getting rid of 'replaced' and
specifying the images in CSS instead of using url(attr). With those changes, I
noted the following possibly undesirable effects:
(1) Saving the image from the context menu (or opening in a new tab or window,
or other context menu operations like copy) always uses the src image instead
of the selected image. Dragging it uses the correct image.
(2) Preloading will always preload the src (and I suspect the normal loader
would do it to so that both the image src and the content: replaced source will
be loaded).
#1 would likely be fixed by a more thorough 'content' implementation. #2 could
presumably be fixed by a CSS-aware preload scanner and by tweaking the img
implementation, but the scanner would have to know how to apply CSS selectors
as it scans, since resolution of a CSS selector is what determines the right
attribute to load. The problem though is when attempting to implement a
polyfill of some kind. The polyfill would not be able to prevent 'src' from
loading as an additional resource. This could possibly be addressed by not
specifying a regular 'src' at all when using a polyfill.
Other than these two details, it seems like a good solution to the problem.
Implementing url(attr()) and these quality-of-implementation improvements would
possibly be simpler than src-n as currently specified, and it exposes a lot
less new syntax.
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, 2013, at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth w...@adambarth.com wrote: Do you have an alternative proposal aside from src-N? Recall that src-N has been rejected by WebKit and therefore is no longer viable. Hey, WebKit, what's your answer if we just take src-N and use a || separator to cram them all into a single attribute? Otherwise identical proposal; none of this gradually expand srcset thing. I think this is a terrible idea, and plenty of actual authors agree with me, but if multiple attributes is the one thing that's acting as a deal-killer for implementors, then screw it, we can mitigate the pain with an OM later. May god have mercy on our souls, etc. I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows: The src-n proposal with the following changes seems likely reasonable: - In a single attribute (ideally named srcset to avoid gratuitous renaming) with || or some other separator - viewport-urls syntax removed or changed to be more human-understandable The latest style-based img/content proposal seems reasonable if the following issues could be addressed: - Always loads src per current browser behavior (might be fixable by omitting 'src' attribute). - Not obvious if preload scanning can reasonably be expected to resolve CSS selectors (hopefully parser/preloading experts can weigh in). I personally somewhat prefer the style-based proposal if the issues are addressed, as it has less surface syntax. It would probably also have to be combined with vanilla x-only srcset to do resolution scaling combined with art direction, without forcing sizes to be set explicitly. Regards, Maciej
Re: [whatwg] The src-N proposal
On Nov 16, 2013, at 11:30 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Nov 16, 2013 at 10:54 AM, Timothy Hatcher timo...@apple.com wrote: My objections were mostly about semantics and not purely aesthetic. I also wasn't the only one to raise concerns on webkit-dev. To represent the WebKit community concerns as “personal” is disingenuous. I don't pretend to represent the entire WebKit community, and neither should you. This entire discussion, for months, has been entirely about syntax. I don't think I've seen a single person talk about semantics, nor do I think it would make much sense to do so. The aesthetic concerns *are* personal, as it's an opinion about whether you think it looks good and is understandable or not. Some people like it, some people don't. It's not a big deal. One key aspect of this functionality is developer ergonomics, i.e. making it easy to read and write the correct syntax, both by hand and with tools. What you dismiss as aesthetics matters quite a bit to this. Regards, Maciej P.S. Neither Tim nor I nor any WebKit developer is speaking for the WebKit community as a whole or Apple as a whole unless we say so explicitly.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 12, 2013, at 9:50 AM, Adam Barth w...@adambarth.com wrote:
On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst derer...@gmx.ch wrote:
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a
simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can
be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of approach
is not part of the discussion?
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Content authors can already do what is described above, and in fact often do.
However, a div with a background-image property set is not the same as an
img in practice. Here are a few differences:
(1) There's no ready way to have an element size automatically to its
background-image (the way an img will to its src by default).
(2) In general, browsers will not provide the same user interaction operations
for a background image as for a content image in an img element (e.g. ability
to drag it elsewhere, context menu items to save it, etc).
(3) Assistive technologies will ignore background image holding divs for which
no textual equivalent has been provided (as opposed to img, where they do
something like reading the filename, or just indicate the presence of an image
without labeling it).
(4) Software that processes content to look for images may treat content images
in img differently from images specified as backgrounds, for instance by
assuming background images are decorative and therefore less meaningful and/or
less related to search terms in text on the page.
Some of the above may be addressable by using the 'content' property instead of
the 'background-image' property, though using 'content' on an element as
opposed to a :before or :after pseudo does not work reliably cross-browser.
Regards,
Maciej
Re: [whatwg] The src-N proposal
On Nov 10, 2013, at 12:20 AM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. The way you avoid complexity in such things is that you don't solve the overall problem, you solve small segments of the problem (e.g. in script or CSS), then pick the solution you want. So for example, we could have a script to handle image grids, another to handle simple cases where as the window gets wider you display more context in the image, etc. If all these scripts have some common features they all need (e.g. the ability to work with pre-parsing to say which image they need first, so it can be fetched early) then we can provide that common core. This is similar to AppCache vs Alex's ServiceWorkers. AppCache addresses a small set of use cases, probably not enough. ServiceWorkers provides the tools to address a lot of use cases, but isn't directly itself a solution; you use it to build solutions. Another example would be the WebForms2 repetition model, vs Rafael's template. The repetition model idea solved some specific use cases, but trying to make it solve all use cases would be a hugely complicated endeavour and would be really ugly. template provides a tool with which you can build specific solutions, but isn't itself a direct solution. I basically agree with Ian. Let's address the simple use cases first (i.e., device-pixel-ratio switching) and worry about the more complex use cases in the future. I agree with this too. It just needs to be noted that there isn't an obvious choice of simple primitive to solve the somewhat more complex cases, assuming they are common enough that we care about preload scanning working for them. So we may have to come back to them at some point. Regards, Maciej
Re: [whatwg] The src-N proposal
On Nov 8, 2013, at 11:46 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. The way you avoid complexity in such things is that you don't solve the overall problem, you solve small segments of the problem (e.g. in script or CSS), then pick the solution you want. So for example, we could have a script to handle image grids, another to handle simple cases where as the window gets wider you display more context in the image, etc. If all these scripts have some common features they all need (e.g. the ability to work with pre-parsing to say which image they need first, so it can be fetched early) then we can provide that common core. If you look at primitives that exist today (excluding src-N), the fundamental thing that's missing is ability to have one of several images correctly selected by the browser at preload time. Other than that, the proposed behavior can be faithfully implemented with script. The closest you can get today is to preload your best guess of the right image (by putting it in src and then changing with script), or preload nothing and only start loading once your script runs. Offhand I can't think of a way to solve the preloading problem other than with a selection syntax that can be performed by the browser. Running script before the preloader does its pass would defeat the purpose of the preloader. Regards, Maciej
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
On Dec 3, 2012, at 11:19 PM, Adam Barth w...@adambarth.com wrote: On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) willc...@chromium.org wrote: Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server. That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that. It also has disadvantage (3): ---8--- (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). ---8--- Yes, but I presumed that multiple script tags is less deviation than the iframe approach. Perhaps that is not the case. Note that in the case of systematically named parts, a single inline script could document.write() the relevant sequence of external script tags, if verbosity is the concern. But it would indeed be different. Do you expect the multipart idea would work with no syntax change in the markup currently embedding the libraries? If so, how? Content negotiation? UA sniffing? Regards, Maciej
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) willc...@chromium.org wrote: Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server. That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that. - Maciej Generally speaking, a browser will map a single resource request to a single stream, which would prevent chunked processing by the browser without multipart/mixed. One could imagine working around this by splitting the single resource into multiple resources, and then relying on SPDY priorities to ensure sequential delivery, but that is suboptimal due to having limited priority levels (4 in SPDY/2, 8 in SPDY/3), and many of them are already used to indicate relative priority amongst resource types ( https://code.google.com/p/chromium/source/search?q=DetermineRequestPriorityorigq=DetermineRequestPrioritybtnG=Search+Trunk ). On Mon, Dec 3, 2012 at 1:40 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Dec 3, 2012 at 10:14 PM, Adam Barth w...@adambarth.com wrote: The HTTP server would then break script.js into chunks that are safe to execute sequentially and provide each chunk as a separate MIME part in a multipart/mixed response. Is it expected that SPDY will take much longer than getting this supported in all browsers? Or am I missing how SPDY will not address this problem? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
It might be good to use a custom MIME type instead of multipart/mixed. multipart/mixed can represent arbitrary heterogenous sequences of types, which is not the desired semantic here - you want a sequence of all text/javascript types. It also has a syntactic affordance for conveying a MIME type per chunk, which is unnecessary in this case. Since browsers will likely need custom logic for this case anyway, I think it might be better to have a multipart/javascript type. Note: if this feature is needed for other script types, let's say vbscript, you could mint distinct types like multipart/vbscript, or use a MIME parameter: multipart/script; type=text/javascript On Dec 3, 2012, at 1:14 PM, Adam Barth w...@adambarth.com wrote: == Use case == Load and execute script as quickly as possible. == Discussion == Currently, there are a number of ways to load a script from the network and execute it, but none of them will actually load and execute the script as fast as physically possible. Consider the following markup: script async src=path/to/script.js/script In this case, the user agent will wait until it receives the last byte of script.js from the network before executing the first byte of script.js. In principle, the user agent could finish executing script.js sooner if it could overlap some of the execution time with some of the network latency, for example by executing a chunk of the script while waiting for the bytes for the next chunk to arrive from the network. Unfortunately, without additional information, the user agent doesn't know where safe chunk boundaries are located. Picking an arbitrary byte boundary is likely to cause a syntax error, and even picking an arbitrary JavaScript statement boundary will change the semantics of the script. The user agent needs some sort of signal from the author to know where the safe chunk boundaries are located. == Workarounds == The simplest work around is to break your script into several pieces: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Now, script-part1.js will execute before the user agent has received the last byte of script-part3.js. Unfortunately, this approach does not make efficient use of the network. Specifically, if the three parts are retrieved from the network in parallel, then the user agent might receive a byte from script-part3.js before receiving all the bytes of script-part1.js, wasting network bandwidth (because the bytes from script-part3.js are not useful until all of script-part1.js is received an executed). A more sophisticated workaround is to use an iframe element rather than a script element to load the script: iframe src=path/to/script-in-markup.html/iframe In this approach, script-in-markup.html is the following HTML: script [... text of script-part1.js ...] /script script [... text of script-part2.js ...] /script script [... text of script-part3.js ...] /script Now the bytes of the script are retrieved from the network in the proper order (making efficient use of bandwidth) and the user agent can overlap execution of the script with network latency (because the script tags delineate the safe chunks). This approach is used in production web applications, including Gmail, to load and execute script as quickly as possible. If you inspect a running copy of Gmail, you can find this frame---it's the one with ID js_frame. Unfortunately, this approach as a number of disadvantages: (1) Creating an extra iframe for loading JavaScript is not resource efficient. The user agent needs to create a number of extra data structures and an extra JavaScript environment, which wastes time as well as memory. (2) Authors need to write their scripts with the understanding that the primary callers of their code will do so from another frame. For example, the instanceof operator might not work as expected if they ask whether an object from the caller (i.e., from the parent frame) is an instance of a constructor from the callee's environment (i.e., from the child frame). (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). == Proposal == The script element should support multipart/mixed. == Details === The main ingredient that we're missing is a way for the author to signal to the user agent which chunks of scripts are safe to execute in parallel with loading subsequent chunks from the network. Fortunately, the web platform already has a mechanism for breaking a single HTTP response body into chunks that are processed sequentially: multipart/mixed. For example, if an HTTP server
Re: [whatwg] proposal for a location.domain property
On Nov 29, 2012, at 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak m...@apple.com wrote: I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Yes, but for the URL http://www.google.co.uk/; you would need to have publicsuffix.org information in order to determine that the effective domain is google.co.uk and not co.uk. I'm not going to add this because cookies and document.domain are not good use cases for this. Cookies should eventually move to an origin-based security model (probably via some kind of opt-in) and document.domain should simply be avoided. (Ian asked me to reply to this thread https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL Standard now deals with these attributes.) To be clear, I don't support adding either location.domain or location.tld. It was messages earlier in the thread that asked for it. My remark above was just a pedantic correction. - Maciej
Re: [whatwg] A plea to Hixie to adopt main
On Nov 7, 2012, at 8:52 AM, Ojan Vafai o...@chromium.org wrote: On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com wrote: My impression from TPAC is that implementors are on board with the idea of adding main to HTML, and we're left with Hixie objecting to it. For those of use who couldn't make it, which browser vendors voiced support? I assume Opera since you're writing this thread. I personally think main would be useful. I don't think it has a huge benefit, but it has modest benefits, like aside, header, footer and section. I also think the implementation costs are low. The reasons I think it has some benefits: - Even though heuristics (such as the scooby-doo algorithm or even guesses based on role or class, or the layout) will always be necessary in some cases, it's still good to have a simple and relatively trustworthy marker of the main content. This is useful both for accessibility purposes and for other browser features that want to find the main content. In many cases, we have found that even when semantics can be heuristically inferred, having an explicit marker is still useful. For example, you can usually guess that some text is an address, but we still have a microformat that helps identify such data unambiguously. - From a language design perspective, it seems inelegant to identify the main content solely by what it is not. I realize that this is a matter of taste and that tastes may differ. By analogy, in imperative programming languages that have a main function, it is generally marked with as specific name rather than just by not being any of the non-main functions. This is not perfectly analogous, but it still seems motivating to me. - The Scooby-Doo algorithm is not actually defined in HTML5 afaict so I am not sure what the spec recommends to find the main content or which elements should be excluded. I presume that header, nav, footer and aside are excluded. What about address? small? Arbitrary other elements with non-main ARIA landmark roles? It seems insufficient to me to say that the use case of finding the main content is satisfied by an algorithm that's ambiguous and not actually defined anywhere. Given the state of play, authors have no way to be confident that their main content can be identified correctly, and implementors have no way to know how to find it. - I'm not confident that the sectioning elements in HTML5 exhaustively cover all possible forms of non-main content. If not, then it's likely that authors will have legitimate reason to have non-main content inside body which cannot reliably be skipped by the Scooby-Doo algorithm. Overall, I would not fall on my sword to get the main element into WebKit but I would not reject a patch to add it either, assuming a sufficiently good spec exists for it somewhere. This idea doesn't seem to address any pressing use-cases. I don't expect authors to use it as intended consistently enough for it to be useful in practice for things like Safari's Reader mode. You're stuck needing to use something like the Scooby-Doo algorithm most of the time anyways. I don't outright object, but I think our time would be better spent on addressing more pressing problems with the web platform. The same argument could have been made for article, but the implementation cost was so low that the benefit didn't have to be huge. I think the same applies to main. Regards, Maciej
Re: [whatwg] Improving autocomplete
(1) If this API fills in a form completely based on stored data, and not by completing the user's typing, then it is autofill rather than autocomplete. (2) If this API provides the ability to get user information without even having a visible form, then it's not clear that it is even really autofill. It's just requestUserInformation() or something. (3) This API has important privacy and even security considerations. You have to tell the user exactly what you are going to fill in to the site before they approve. Unfortunately, most won't read it. If sites are asking for so much info that they have to split pages for usability, then it seems likely the UI that tells the user what the site is asking for will be impractical for most users to meaningfully review. This becomes especially dangerous if the mechanism can fill in credit card info. I would be very nervous if the browser could at any moment pop up a dialog that would submit all my credit card info to a dubious site if I slip and click the wrong button. Can you expand more on what thought you have given to the security considerations? (4) Should this API be limited to initiation during a user interaction? That would reduce the ability of sites to spam the user with such forms. (5) What makes the UI unspoofable? Is that an important part of the security model? Regards, Maciej On Oct 26, 2012, at 12:24 AM, Elliott Sprehn espr...@gmail.com wrote: Several of us on the Chrome team have been thinking about the challenges of filling out long forms full of personal information. We've noticed that site authors split up their forms across multiple pages to avoid overwhelming their users with one single massive form [1]. This is particularly bad on mobile where we've observed some popular retailers splitting their forms into six or more pages in an attempt to optimize their flow for a small screen. This unfortunately defeats many of the advantages of existing browser autocomplete. In researching this we’ve found that with a few changes built on the existing HTML autocomplete spec [2] we can allow authors to recombine their forms and enable browsers to provide more useful autocomplete. 1) HTMLFormElement.prototype.requestAutocomplete() Asks the user agent to asynchronously present a UI for performing full form autocomplete using the already spec’ed autocomplete attributes [2] used in the form. In concept this is very similar to prompt() except the UA could provide a streamlined experience for filling in information in large chunks. For example you could imagine choosing a shipping address from a drop down instead of presenting multiple inputs. 2) Simple event named “autocomplete” This event is dispatched on the form element after the UI presented by requestAutocomplete() is closed if the form validates after having filled each input and firing all necessary input events like “change”. 3) Simple event named “autocompletecancel” This event is dispatched on the form if the UI is canceled. Using this API authors may simplify their input flows from forms spread over multiple pages to just a few clicks on a single page all while getting all the autocomplete goodness! Authors can also display no forms at all to users of a browser who implements this proposal for one click checkout experiences which are important on mobile devices. The proposed additions also improve security on the web as users will become accustomed to inputting their sensitive data through an unspoofable UI that could warn users of phishing sites or even allow them to choose per domain security images. We’d love to hear the thoughts of other implementers on this proposal. :) [1] ex. Retailers often split forms into credit card, billing address, and shipping address pages. [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete - E
Re: [whatwg] Features for responsive Web design
On Oct 11, 2012, at 11:07 AM, Markus Ernst derer...@gmx.ch wrote: Am 11.10.2012 18:36 schrieb Ian Hickson: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html It looks like my English is not perfectly understandable, I am sorry I am not a native English speaker. I did not try to state the use case was solved. I have been following the discussion in this list quite closely. 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. - Maciej
Re: [whatwg] Features for responsive Web design
On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ appears to be 299dpi http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi These devices aren't out yet, but I suspect browsers would be more-or-less as high-dpi as possible. This page lists several devices with physical DPI higher than 288 (3x the nominal CSS dpi) but none with a CSS pixel ratio greater than 2x. (To be fair, the data is incomplete and may be inaccurate, though to my knowledge the entries for Apple devices are all correct). So it's not a given that the cited hardware dpi values would lead to higher CSS pixel ratios in the corresponding software. Regards, Maciej
Re: [whatwg] [canvas] Path object
Charles, Your whole message here is bizarre and disruptive: - Your claims about the data gathering capabilities of varying browser vendors are arbitrary, incorrect (in the cases I know of), and off-topic for this list. - Your reference to the Hixie-Atkins draft is unwarranted and strange. - There has been no announcement of HTML6, let alone a schedule for it. - Mysteriously citing an Apple employee also seems strange and rude. Please reconsider this style of communication, and let's stick to discussion of actual technical issues on this list. Regards, Maciej On Oct 2, 2012, at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: On Oct 2, 2012, at 6:05 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@gmail.com wrote: What of the fact that this breaks existing pages with input id=Path that access it as just Path? Historically this has been a non-starter for new APIs. Surely it's not a non-starter in general, or else no new APIs could ever be added to the platform--at worst it just means picking a less generic name. I assume that's not strictly needed; URL must be a more common ID than Path. (Path makes me think of URL paths, though. Something like DrawPath would be a little clearer.) What about unifying all of these as: new GraphicsPath() new GraphicsLinearGradient() new GraphicsRadialGradient() new GraphicsPattern() and fixing HTML5 canvas to support these new constructors instead? I'm a little surprised about the window.URL change that went through recently. There must be tons of input id=URL's around, and lots of old form generating code accessed them through window.id. @hixie: How was it decided that this wasn't going to break the web? Mozilla has a massive platform for collecting and analyzing user/software feedback. I'd imagine they've got good metrics on web-breaking moves. Chrome, from my experience, relies on bug reports on their issues site; Microsoft and Apple go slow and keep things opaque/in-house. WHATWG watches, suggests and makes changes based on the eventual consensus. As for html5 Canvas; other than the accessibility issues addressed in the past two years, I wouldn't say it's broken. We're now looking at a new version of it. I think it was called version 5 by Hixie. I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. So, it's on the table. As always, browser vendors will decide on the actual direction. I'm still for making a snapshot with createPath and an opaque CanvasPath, and saving version 5 for the more distant 3-year future and HTML6. The W3C and WHATWG have gone ahead with version 5, with support from an Apple employee. -Charles
Re: [whatwg] New URL Standard
Excellent work. Did you use tests while making this and if so did you save them? It might be worthwhile to check all the browsers against the spec. Cheers, Maciej On Sep 21, 2012, at 8:16 AM, Anne van Kesteren ann...@annevk.nl wrote: I took a crack at defining URLs: http://url.spec.whatwg.org/ At the moment it defines parsing (minus domain names / IP addresses) and the JavaScript API (minus the query manipulation methods proposed by Adam Barth). It defines things like setting .pathname to hello world (notice the space), it defines what happens if you resolve http:test against a data URL (you get http://test/;) or http://teehee (you get http://teehee/test;). It is based on the various URL code paths found in WebKit and Gecko and supports the \ as / in various places because it seemed better for compatibility. I'm looking for some feedback/ideas on how to handle various aspects, e.g.: * data URLs; in Gecko these appear to be parsed as part of the URL layer, because they can turn a URL invalid. Other browsers do not do this. Opinions? Should data URLs support .search? * In the current text only a select few URLs support host/port/query. The rest is solely path/fragment. But maybe we want mailto to support query? Should it support host? (mailto supporting e.g. host would also mean normalising host via IDNA toASCII and friends. Not sure I'm fond of that.) * Advice on file URLs would be nice. * IDNA: what are your plans? IDNA2003 / IDNA2008 / UTS #46 / something else? It would be nice to get agreement on this. * Terminology: should we align the terminology with the API or would that just be too confusing? Thanks! PS: It also does the query encoding thing correctly for the first time ever in the history of URL standards although the wording can probably be improved. -- http://annevankesteren.nl/
Re: [whatwg] Features for responsive Web design
On Sep 5, 2012, at 12:07 AM, Fred Andrews freda...@live.com wrote: ... 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. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k 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 img element is not computable until all external stylesheets have loaded, as you have written it. 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. Regards, Maciej
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Someone earlier in the thread mentioned that this feature sounds an awful lot like rel=noreferrer, which has been in WebKit for several years: http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ It is also mentioned in the official link relation registry: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Do you have a use case for your new proposal that is not handled by a href=... rel=noreferrer target=_blank? Does it have a materially different effect? (I can't tell.) Regards, Maciej On Aug 27, 2012, at 5:29 PM, Charlie Reis cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 6 Jun 2012, Charlie Reis wrote: I've posted a new proposal to the WhatWG wiki to give web sites a way to open a link in an unrelated browsing context. These links would open in a new window with no script connections back to the original site, which is useful for web apps like Gmail that open user-contributed links. Also, this could allow multi-process browsers like Google Chrome to open the new page in a separate process. Any feedback on the proposal is appreciated! http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts It's not entirely clear to me what the desired behaviour is here. Which of the following are considered features that we need to provide? Which are secondary goals, which are non-goals, which are anti-goals? I think our discussion found this feature would be most useful if the new page was unable to find its opener, so I'd group things as follows. Primary goals: + have the new page use a different event loop if possible (new process) + have the window of the new page not be able to reach the opener via a named window.open() or target= As a result, I think these are also necessary features: + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have window.opener not be set + have the window.name of the new page be set to Secondary goals: + have the sessionStorage not be cloned for the new page's browsing context Non-goals: + have the new page be in the same browsing context Anti-goals: + have the referer header be cleared on the load of the new page Does this need to be done from window.open()? Yes. For example, Gmail uses window.open() for the links in emails, but would like the links to open in an unrelated context. From a href? Yes. For example, links to switch between apps within a domain would be useful to have open in an unrelated context (e.g., the black bar at the top of Google pages). From form action? I don't know of any immediate use cases for this, but it might be nice for consistency. Is this a symmetric feature? Sorry, I'm not sure what you mean by symmetric here. The page opened in the unrelated context may also be able to open pages in another unrelated context. At a more fundamental level: what are the use cases here? Is it just e-mail clients that want to open links? Links in email clients is one use case. For user agents that can open such links in a different event loop, another use case is to allow multiple independent apps under the same domain to run in parallel, even when opening one app from another. (For example, Chrome could open links to different Google apps like Search, Maps, Mail, etc, in different processes.) Even in user agents where all pages share the same event loop, this can be useful to help enforce modularity in large applications (e.g., stopping a developer in one part of a large site from introducing a scripting dependency on another part of the site). That's admittedly a secondary benefit, and not the primary goal. What are the attack scenarios? Is it just links in e-mails getting at the e-mail app somehow? The attack scenarios are about protecting any web app from unwanted script calls or navigation attempts from untrusted pages in windows that it opens. You could imagine anything from a mail client to a news reader to a social network using it for links to external content. Beyond defending against those attacks, the feature is also about allowing unrelated pages to run on parallel event loops, so they aren't blocked on each other. Without more details like the above it's hard to evaluate the proposals. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' I hope that clarifies things! It wasn't initially clear whether preventing any access from the new page to the opener window (e.g., by finding the named window) was necessary, but it does seem like the feature would be most useful if that were the case. Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
I overlooked that it's also in the spec itself, not just the registry: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer Regards, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak m...@apple.com wrote: Someone earlier in the thread mentioned that this feature sounds an awful lot like rel=noreferrer, which has been in WebKit for several years: http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ It is also mentioned in the official link relation registry: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Do you have a use case for your new proposal that is not handled by a href=... rel=noreferrer target=_blank? Does it have a materially different effect? (I can't tell.) Regards, Maciej On Aug 27, 2012, at 5:29 PM, Charlie Reis cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 6 Jun 2012, Charlie Reis wrote: I've posted a new proposal to the WhatWG wiki to give web sites a way to open a link in an unrelated browsing context. These links would open in a new window with no script connections back to the original site, which is useful for web apps like Gmail that open user-contributed links. Also, this could allow multi-process browsers like Google Chrome to open the new page in a separate process. Any feedback on the proposal is appreciated! http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts It's not entirely clear to me what the desired behaviour is here. Which of the following are considered features that we need to provide? Which are secondary goals, which are non-goals, which are anti-goals? I think our discussion found this feature would be most useful if the new page was unable to find its opener, so I'd group things as follows. Primary goals: + have the new page use a different event loop if possible (new process) + have the window of the new page not be able to reach the opener via a named window.open() or target= As a result, I think these are also necessary features: + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have window.opener not be set + have the window.name of the new page be set to Secondary goals: + have the sessionStorage not be cloned for the new page's browsing context Non-goals: + have the new page be in the same browsing context Anti-goals: + have the referer header be cleared on the load of the new page Does this need to be done from window.open()? Yes. For example, Gmail uses window.open() for the links in emails, but would like the links to open in an unrelated context. From a href? Yes. For example, links to switch between apps within a domain would be useful to have open in an unrelated context (e.g., the black bar at the top of Google pages). From form action? I don't know of any immediate use cases for this, but it might be nice for consistency. Is this a symmetric feature? Sorry, I'm not sure what you mean by symmetric here. The page opened in the unrelated context may also be able to open pages in another unrelated context. At a more fundamental level: what are the use cases here? Is it just e-mail clients that want to open links? Links in email clients is one use case. For user agents that can open such links in a different event loop, another use case is to allow multiple independent apps under the same domain to run in parallel, even when opening one app from another. (For example, Chrome could open links to different Google apps like Search, Maps, Mail, etc, in different processes.) Even in user agents where all pages share the same event loop, this can be useful to help enforce modularity in large applications (e.g., stopping a developer in one part of a large site from introducing a scripting dependency on another part of the site). That's admittedly a secondary benefit, and not the primary goal. What are the attack scenarios? Is it just links in e-mails getting at the e-mail app somehow? The attack scenarios are about protecting any web app from unwanted script calls or navigation attempts from untrusted pages in windows that it opens. You could imagine anything from a mail client to a news reader to a social network using it for links to external content. Beyond defending against those attacks, the feature is also about allowing unrelated pages to run on parallel event loops, so they aren't blocked on each other. Without more details like the above it's hard to evaluate the proposals. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' I hope that clarifies things! It wasn't initially
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
James pointed out to me that the proposal explains the difference to noreferrer, which is essential that it *does* send a referrer, but has the rel=noreferrer behavior of nulling out window.opener. I'm still not clear on the use case for nulling the opener but still sending the Referer header. It seems like it is better for mail clients to clear referrer. What kinds of web apps need to open new windows and null window.opener, but still send Referer? The reason I'm asking is that it seems regrettable to have two link types with such similar but subtly different behavior. Cheers, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak m...@apple.com wrote: Someone earlier in the thread mentioned that this feature sounds an awful lot like rel=noreferrer, which has been in WebKit for several years: http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ It is also mentioned in the official link relation registry: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Do you have a use case for your new proposal that is not handled by a href=... rel=noreferrer target=_blank? Does it have a materially different effect? (I can't tell.) Regards, Maciej On Aug 27, 2012, at 5:29 PM, Charlie Reis cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 6 Jun 2012, Charlie Reis wrote: I've posted a new proposal to the WhatWG wiki to give web sites a way to open a link in an unrelated browsing context. These links would open in a new window with no script connections back to the original site, which is useful for web apps like Gmail that open user-contributed links. Also, this could allow multi-process browsers like Google Chrome to open the new page in a separate process. Any feedback on the proposal is appreciated! http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts It's not entirely clear to me what the desired behaviour is here. Which of the following are considered features that we need to provide? Which are secondary goals, which are non-goals, which are anti-goals? I think our discussion found this feature would be most useful if the new page was unable to find its opener, so I'd group things as follows. Primary goals: + have the new page use a different event loop if possible (new process) + have the window of the new page not be able to reach the opener via a named window.open() or target= As a result, I think these are also necessary features: + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have window.opener not be set + have the window.name of the new page be set to Secondary goals: + have the sessionStorage not be cloned for the new page's browsing context Non-goals: + have the new page be in the same browsing context Anti-goals: + have the referer header be cleared on the load of the new page Does this need to be done from window.open()? Yes. For example, Gmail uses window.open() for the links in emails, but would like the links to open in an unrelated context. From a href? Yes. For example, links to switch between apps within a domain would be useful to have open in an unrelated context (e.g., the black bar at the top of Google pages). From form action? I don't know of any immediate use cases for this, but it might be nice for consistency. Is this a symmetric feature? Sorry, I'm not sure what you mean by symmetric here. The page opened in the unrelated context may also be able to open pages in another unrelated context. At a more fundamental level: what are the use cases here? Is it just e-mail clients that want to open links? Links in email clients is one use case. For user agents that can open such links in a different event loop, another use case is to allow multiple independent apps under the same domain to run in parallel, even when opening one app from another. (For example, Chrome could open links to different Google apps like Search, Maps, Mail, etc, in different processes.) Even in user agents where all pages share the same event loop, this can be useful to help enforce modularity in large applications (e.g., stopping a developer in one part of a large site from introducing a scripting dependency on another part of the site). That's admittedly a secondary benefit, and not the primary goal. What are the attack scenarios? Is it just links in e-mails getting at the e-mail app somehow? The attack scenarios are about protecting any web app from unwanted script calls or navigation attempts from untrusted pages in windows that it opens. You could imagine anything from a mail client to a news reader to a social network using it for links to external content. Beyond defending against those attacks, the feature is also about allowing unrelated pages to run
Re: [whatwg] Feedback on Web Worker specification
To expand a little on rationale for what Jeffrey said: We're working on an experimental preference setting for WebKit to block data storage in a third-party context, similar to the third-party cookie blocking feature in many browsers, but covering all forms of client-side storage. The intent of this is to make it more difficult for third-party content (such as ads or social media like buttons or similar) to track you across different sites, if you enable the feature. In thinking about the design, we came to the conclusion that SharedWorkers are actually a form of client-side shared storage. In particular, you could set a global variable in a SharedWorker, and then vend it to subframes from the same domain on other pages. It seems that to match the intent of the feature, we have to do one of two things: (1) Refuse access to SharedWorkers in a third-party context when the feature is enabled. This doesn't seem sanctioned by the spec, though other storage features have an explicit escape clause to refuse access based on privacy/security policy. (2) Create a dedicated worker instead of connecting to or spawning a shared worker when a third party context attempts to access a SharedWorker and the feature is enabled. We think, but are not sure, that something like this is sanctioned by the spec. We think (1) would be better and that's what we plan to do, unless other implementors feel strongly about taking the other approach. In either case, more clarity would be useful. Regards, Maciej On Aug 22, 2012, at 1:29 PM, Jeffrey Pfau jp...@apple.com wrote: Hi, 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. Adding something like the following (based on the localStorage policy clause) to the SharedWorker constructor steps would help: The user agent may throw a SecurityError exception instead of returning a SharedWorker object if the request violates a policy decision (e.g. if the user agent is configured to not allow the script to share data). What do you think? Jeffrey
Re: [whatwg] register*Handler and Web Intents
I also agree with Henri and James. I would be opposed to implementing the feature in WebKit the way it is currently proposed. The aesthetic benefit is not great enough to be worth the breakage. Consider in particular that the following proposed markup: intent action=edit type=image/png scheme=mailto href= title=Foo disposition= /intent could just as easily be: link intent action=edit type=image/png scheme=mailto href= title=Foo disposition= or: meta intent action=edit type=image/png scheme=mailto href= title=Foo disposition= Both of which are no more verbose and read about as well. - Maciej On Aug 6, 2012, at 8:11 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, Aug 3, 2012 at 12:00 PM, James Graham jgra...@opera.com wrote: I agree with Henri that it is extremely worrying to allow aesthetic concerns to trump backward compatibility here. Letting aesthetic concerns trump backward compat is indeed troubling. It's also troubling that this even needs to be debated, considering that we're supposed to have a common understanding of the design principles and the design principles pretty clearly uphold backward compatibility over aesthetics. I would also advise strongly against using position in DOM to detect intents support; if you insist on adding a new void element I will strongly recommend that we add it to the parser asap to try and mitigate the above breakage, irrespective of whether our plans for the rest of the intent mechanism. I think the compat story for new void elements is so bad that we shouldn't add new void elements. (source gets away with being a void element, because the damage is limited by the /video or /audio end tag that comes soon enough after source.) I think we also shouldn't add new elements that don't imply body when appearing in in head. It's great that browsers have converged on the parsing algorithm. Let's not break what we've achieved to cater to aesthetics. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] alt= and the meta name=generator exception
On Aug 7, 2012, at 9:53 AM, Michael[tm] Smith m...@w3.org wrote: Anyway, do you have a concrete suggestion for an alternate name? I'm not wedded to generator-unable-to-provide-required-alt and I doubt Hixie is either. It's just a proposal that came up after 15 minutes of brainstorming on IRC. That said, Hixie's already articulated the reasons behind the choice of that name. Lacking any other proposed alternative, it's hard to have any kind of productive discussion about the name. Lacking any other proposed alternative? Not only do we have Ted's original suggestion of relaxed, but also this whole subthread of name suggestions: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0038.html - Maciej
[whatwg] Missing alt attribute name bikeshedding (was Re: alt= and the meta name=generator exception)
On Aug 1, 2012, at 12:56 AM, Ian Hickson i...@hixie.ch wrote: We briefly brainstormed some ideas on #whatwg earlier tonight, and one name in particular that I think could work is the absurdly long img src=... generator-unable-to-provide-required-alt= This has several key characteristics that I think are good: - it's long, so people aren't going to want to type it out - it's long, so it will stick out in copy-and-paste scenarios - it's emminently searchable (long unique term) and so will likely lead to good documentation if it's adopted - the generator part implies that it's for use by generators, and may discourage authors from using it - the unable and required parts make it obvious that using this attribute is an act of last resort Here's a review of other proposed names and a few new ideas: noalt Pro: brief Con: not very explanatory, so perhaps more likely to be misused relaxed [suggested by Ted] Pro: correctly conveys relaxed validation Con: not clear what is relaxed or why incomplete [suggested by Laura] Pro: correctly conveys that a non-decorative content image is incomplete without a textual equivalent Con: not clear what is incomplete or why unknown Pro: correctly conveys the reason for omitting alt, i.e. that the name is unknown to the generator Con: might not be clear that it is not for human authors unknown-to-generator Pro: correctly conveys intended generator use Con: not totally clear what it is that is unknown I don't have a strong opinion, but I think generator-unable-to-provide-required-alt might be long to the point of silliness. Cheers, Maciej
Re: [whatwg] A mechanism to improve form autofill
On Jul 25, 2012, at 11:21 PM, Aryeh Gregor a...@aryeh.name wrote:
I would also like to point out that this feature seems to overlap with
not only type= (as has been pointed out), but inputmode= as well,
and for that matter pattern=. I think it would be quite unfortunate
if authors found themselves writing things like
input inputmode=numeric pattern=\d{16} autocompletetype=cc-num
because that's logically pretty redundant. But maybe it's the only
way to preserve our sanity, because it allows authors to figure out
what combination of features they need for their inputs instead of us
trying to figure out in advance what the possibilities are.
The specific combo of features you list is highly foreseeable. You may be right
that there will be harder to predict scenarios.
the flip side is that a multidimensional matrix of features affecting form
elements is more complicated to understand, more likely to be implemented in a
buggy way, and more likely to be used wrong by authors.
Regards,
Maciej
Re: [whatwg] A mechanism to improve form autofill
On Jul 23, 2012, at 4:41 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jan 2012, Kornel LesiÅ~Dski wrote: But even if single-mixed-login-field autocomplete was desired, then perhaps a mixed type would work too: input type=username email How about merging autocompletetype with autocomplete then? It looks sensible to me: input autocomplete=off input autocomplete=email Yeah, using autocomplete= in this way makes a lot of sense I think. For some of these fields, autocomplete= as a hint to autocompletion seems sufficient. However, I think some may logically be a distinct input type as well. Some of the information represented in the proposal below is also redundant with existing type values (so it needs to be specified either twice or in a conflicting way). Studying the forms in the listing cited above, it seems that fields fall into these categories: Separate forms all found in the same form, e.g. for pages that contain multiple products each with their own set of fields, only one product of which is shown at a time. At a high level, the use agent should treat each of these as a separate form for autofill purposes. Each of these can have information for different people or facets of people: - shipping information - billing information - generic user information (e.g. when it's not a shipping order form) Each of these sections can then have subinformation: - name (and its subfields, such as honorific-prefix, nickname, etc) - organisation name, the user's organisation-title - physical address (and its subfields, such as city, state, etc) - contact information category, e.g. home, work, cell, fax - each of which has subinformation such as email, tel (and their subfields, such as country-code) There's already input type values of tel and email, so specifying them again seems redundant. I'm assuming here a distinction between type= and autocomplete= -- anything that would change the appearance or behavior of the control, the syntax accepted, or the input affordances given to the user, should be a type=; and autocomplete= should affect autocomplete choices only. If autocomplete were to affect aspects beyond autocomplete, - credit card details (and subfields such as name, exp etc) - personal information (such as bday, url, photo) So we could define the autocomplete= field's value as follows: on, off, or: [section] [subsection] [generic-field | [contact-type] contact-field] ...where section = high-level section name; author-defined string starting with the prefix section- subsection= shipping or billing generic-field = one of: name, honorific-prefix, given-name, additional-name, family-name, honorific-suffix, nickname, organisation-title, organisation, street-address, address-line1, address-line2, address-line3,locality, region, country, postal-code, These all seem fine as text inputs. cc-name, cc-given-name, cc-additional-name, cc-family-name, cc-number, cc-exp, cc-exp-month, cc-exp-year, cc-csc, I think cc-number is worthy of a distinctive type value. Credit card numbers have a distinctive syntax. At the very least, they are numeric and should trigger a numeric keyboard on touch devices and restriction to digits. But they cannot be input type=number because it would be wrong to format and localize the number (with comma or dot separators for instance), and a spinner button is an obviously inappropriate treatment. A similar consideration applies to cc-csc. These should either be assigned distinctive types, or else we need to introduce a new input type for a string of digits that is not to be formatted as a number or treated as a spinner button (input type=digits or input type=numeric). I think it is essential to do that before widely deploying these autocomplete values, or else browsers will start using the autocomplete value to drive behavior of the control itself, which defeats the purpose of having a separate autocomplete attribute. cc-exp subtypes could be distinguished by input type for cases where they are not selects. Or alternately, it would be nice if there was a way to use input type=month in browsers that have support for it, and the traditional two selects or two text fields. language, bday, bday-day, bday-month, bday-year, It's unfortunate that we don't have distinct input types for just a day, just a month, or just a year. sex, url, photo input type=url exists, doesn't seem necessary to also have an autocomplete value. Also, should this not be a contact field? contact-type = home, work, cell, or fax contact-field = one of: email, tel, tel-country-code, tel-national,
Re: [whatwg] A mechanism to improve form autofill
On Jul 25, 2012, at 12:36 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak m...@apple.com wrote: For some of these fields, autocomplete= as a hint to autocompletion seems sufficient. However, I think some may logically be a distinct input type as well. This is also true for the inputmode attribute. In particular its Telephone, E-mail, and URL states. If we add this, we should also add guidance on how type/autocomplete/inputmode work together. Yeah, it seems like having both input type=tel and input inputmode=tel is redundant. If they had different behavior, that would be awful. If they have the same behavior, then why do we need both in the platform? Similarly, I'm confused about the need to have both input type=number and input inputmode=numeric. They are not exactly the same, but it is mysterious that one is a type and the other is the inputmode. Also, neither is appropriate for pure digit strings such as credit card numbers of CVVs, where the thousands separator and negative indicator should never be added, either explicitly by the user or as part of formatting by the UA. Regards, Maciej
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Jul 5, 2012, at 11:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor eocon...@apple.com wrote: As things currently stand in the spec, implementations basically need to keep N+1 bitmaps per canvas, where N is the number of hit regions. I doubt any implementors would be enthusiastic to implement hit regions like this. From a WebKit perspective, we'd much prefer keeping a Path for each hit region, and then simply using isPointInPath for hit testing. This also implies that the current piggybacking of Clear regions that cover the pixels in clearRect() could go away. Yay! :) Bog-standard hit-testing algorithms apply. Keep a single extra canvas around, draw each region into it with a different color. When you're hit-testing, just see what color that pixel is, and look up which region is associated with it. This is extremely fast and simple to implement, and has all the right properties - the topmost region for a given pixel is the one returned. It also doubles the memory cost of the canvas if you use hit regions, which is likely much more than path-based hit testing would cost. - Maciej
Re: [whatwg] make video always focusable and interactive content
On Jun 19, 2012, at 8:43 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi all, I recently experimented with keyboard accessibility of media elements. I found that browsers don't provide a default tabfocus on media elements nor do they provide keyboard interactivity. I had to put explicit @tabindex attributes onto the media elements to allow them to at least receive focus. This is particularly irritating in a screenreader. As the video is specified right now, it is not a tabfocusable element [1] and only interactive [2] when it has controls. This is sufficient for audio elements, which have no visual representation without controls, but isn't right for video, which always renders at least a poster (or a black area). Also, if there are controls specified, they should actually be tabfocusable. In Safari on Mac OS X, we choose what is tab focusable based on OS conventions, where not all controls are in the tab focus cycle by default. For Mac UI, video should not be tab-focusable unless the user has enabled the special tab-to-everything mode. I think the spec should continue to allow this behavior. I think it's fine to also allow the other behavior, where video is focusable by default. I think the spec actually already allows both behaviors when it says: An element is focusable if the user agent's default behavior allows it to be focusable. As with any other control, the default focusability should be up to the UA. Regards, Maciej
Re: [whatwg] AllowSeamless
On May 26, 2012, at 5:16 PM, Adam Barth w...@adambarth.com wrote: Hi whatwg, I've added a proposal to the wiki http://wiki.whatwg.org/wiki/AllowSeamless about letting a document indicate that it is willing to be displayed seamlessly with a cross-origin parent. This proposal is a refinement of the approach previously discussed in this thread: http://old.nabble.com/crossorigin-property-on-iframe-td33677754.html. Let me know if you have any feedback. Hi Adam, Seems like your use case is well motivated. Two points of feedback: 1) In the Alternatives section, you didn't talk about the alternative of a newly created HTTP header, or else extending one of the headers already affecting embedding security, or in general the tradeoffs of header vs. signifier inside the HTML document to be embedded. I don't have a particular pre-existing opinion on this, but it seems like at least some of the precedent in this case is based on HTTP headers, and it would be good to understand the tradeoffs. 2) It seems like, even if it might not be appropriate to require CORS for this use case, it seems like allowing CORS access should at least be sufficient even if not necessary. In other words, if you are prepared to use CORS anyway for other reasons, then it seems like that should also allow seamless embedding. But perhaps this makes the model too complicated.
Re: [whatwg] proposal for a location.domain property
On May 25, 2012, at 4:27 AM, João Eiras jo...@opera.com wrote: On Thu, 24 May 2012 23:02:00 +0200, Maciej Stachowiak m...@apple.com wrote: I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security, and that has proved to be a sounder model. While I acknowledge the use cases for exposing location.domain, it's also likely to become an attractive nuisance that pulls developers in the wrong direction. Although I understand this opinion and agree with it, the domain based security checks are used for cross frame interaction, cookies, security certificates, etc, therefore it has to be specified and documented. When you say cross frame interaction, do you mean just the relatively rare case of document.domain being explicitly set? I agree with you that we must document the right rules for what domains are valid, but I do not think that this requires exposing location.domain explicitly. I don't think adding a location.tld property or location.topDomain would pull developers away from anything. It would just make the legacy domain based security checks a bit more easy to handle and understand. It's the specifications and APIs that tell which security model to use, not the developer. I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Regards, Maciej
Re: [whatwg] The set of supported @type values for script is a bit odd
On May 25, 2012, at 10:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: The list is at http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language or http://dev.w3.org/html5/spec/the-script-element.html#scriptingLanguages depending on which you prefer to read. It seems to include several values that no UA actually supports, apparently because of the way the spec uses the same list to deal with both @language and @type. See compat testing data at https://bugzilla.mozilla.org/show_bug.cgi?id=672814#c6 and the testcase I used to generated that data at https://bug672814.bugzilla.mozilla.org/attachment.cgi?id=627261 At the moment our plan in Gecko is to just implement this list as-is, I think: it's a superset of what everyone implements, and it just doesn't feel worth pushing back on the two Presto-only items and the three no one implements this items. This mail is just a heads-up for people in case they want to protest, before we go ahead and ship this full list in Gecko. If the weird values are just for compatibility, then I think it would be better to change the spec to drop the ones no one implements. I certainly would not want the list of versioned types to expand over time with new JavaScript versions, so there is no need for it to be a consistent or logical set. Cheers, Maciej
Re: [whatwg] proposal for a location.domain property
I agree. Even though there are still legacy features like cookies and
document.domain that use domain-based security, most of the Web platform uses
origin-based security, and that has proved to be a sounder model. While I
acknowledge the use cases for exposing location.domain, it's also likely to
become an attractive nuisance that pulls developers in the wrong direction.
- Maciej
On May 24, 2012, at 10:56 AM, Adam Barth w...@adambarth.com wrote:
IMHO, we should be moving away from using the public suffix list in
the platform rather than adding more APIs that interact with it.
Adam
On Thu, May 24, 2012 at 8:35 AM, Hallvord R. M. Steen
hallv...@opera.com wrote:
Many browser engines use lists of top-level domains to be able to determine
what a server's base domain is. For some use cases it would be interesting
to have this information available to scripts. I list some use cases I can
think of below:
1) Determining in a simple and fool-proof manner that a page is from a given
domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] Make files attribute of the input element writable
On May 22, 2012, at 11:57 PM, Adam Barth w...@adambarth.com wrote: On Tue, May 22, 2012 at 9:16 PM, Maciej Stachowiak m...@apple.com wrote: It seems like making FileList mutable would serve the same use case and would also be more flexible (as you could upload a set of files collected from possibly multiple sources). And it seems like adding is a more likely desired behavior than replacing when dragging files onto a multi-file input. I have not yet fully thought through the security implications of either case. Do you have any security analysis you could share? For instance, is there an exhaustive list of ways a Web page could obtain a FileList, and are we confident that all are safe for this use? A FileList is just a list of File objects: http://www.w3.org/TR/FileAPI/#dfn-filelist Each File object represents the actual file, which means you can use the File API to read the contents of the files on the client already. Also: wouldn't anyone doing fancy drag-n-drop file upload be likely to use XHR for upload rather than a form submission? Not necessarily. In the applications that Nico was working on, he wanted to combine the file upload with other form elements into one POST to the server. Since XHR can upload an arbitrary FormData which it could construct from a FileList, I guess there is no additional risk. But, by the same token, XHR upload of FormData[1] already serves this use case in a more flexible way. You can even make a FormData from the contents of an html form and then add additional File objects. Making the change would (afaict) not serve any new use cases. At most it would be a convenience. Cheers, Maciej [1] http://www.w3.org/TR/XMLHttpRequest/#interface-formdata/
Re: [whatwg] Features for responsive Web design
On May 21, 2012, at 9:37 PM, Kornel Lesiński kor...@geekhood.net wrote: There’s no prior precedent this sort of thing—there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. If 'width' and 'height' attributes on the picture element would do the same thing as they do on img, then they would be setting the size via style, rather than setting intrinsic size. Even if setting the size explicitly affected intrinsic size rather than size computed via style, it would miss the point of intrinsic size, which is that images get automatically the right amount of space based on the image itself. Auto-sizing may not be the right choice for all designs, but it is for some designs. - Maciej
Re: [whatwg] Make files attribute of the input element writable
It seems like making FileList mutable would serve the same use case and would also be more flexible (as you could upload a set of files collected from possibly multiple sources). And it seems like adding is a more likely desired behavior than replacing when dragging files onto a multi-file input. I have not yet fully thought through the security implications of either case. Do you have any security analysis you could share? For instance, is there an exhaustive list of ways a Web page could obtain a FileList, and are we confident that all are safe for this use? Also: wouldn't anyone doing fancy drag-n-drop file upload be likely to use XHR for upload rather than a form submission? Cheers, Maciej On May 22, 2012, at 10:41 AM, Nico Weber tha...@chromium.org wrote: Hi, The files attribute of the input element is currently marked readonly [1], to protect from `myInput.files = /etc/passwd; myForm.submit()`. Since its type is now FileList and not string, that's no longer necessary. Making the attribute writable would allow setting the files property of an input element to dataTransfer.files from a drop handler. For example, I would like to use this to create a larger drop-target for a file input. Here's one request for this functionality: http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input Can the readonly restriction be removed from the spec? Nico 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
Re: [whatwg] Features for responsive Web design
On May 18, 2012, at 3:16 AM, Markus Ernst derer...@gmx.ch wrote: Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). Cheers, Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On May 16, 2012, at 10:39 PM, Jonas Sicking jo...@sicking.cc wrote: I agree that there's no obligation. And I agree that if people here didn't know about the existence of the CG then of course it's not surprising that we didn't engage with the work that was happening there. However I was under the impression that that wasn't the situation here. So while I agree that there was no obligation, it also doesn't seem surprising to me that the people in the CG were unhappy/upset with the resulting outcome. I didn't know about the respimg CG until a few days ago (after a couple of days of discussion of responsive image proposals, and months after Ted first posted his image-set proposal to www-style). Checking after the fact, I could find no mention of the term respimg or anything else uniquely identifying the community group in the archives of wha...@whatwg.org or public-html, and no one from the CG that I asked had a recollection of announcing it here. That's the basis for my assumption that most people here didn't know about the CG while it was working on its proposal. Do you have a basis for assuming otherwise? REgards, Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On May 17, 2012, at 11:20 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 17 May 2012 19:15, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox m...@matthewwilcox.com wrote: A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. FWIW, I wanted to do this, but Google's policy of having us talk to the patents guys before joining CGs turned me off from actually joining. So, I just followed from the side and couldn't interact enough. :/ Is this something that Google might be willing to bend somewhat? I.e., when you're on the CG you're a free-agent and not representing Google? Or, for the sake of politics, could it be worked around in that instead of joining the CG you keep track of things via the RSS feed (it is after all public) and post to the WHATWG mailing list with observations every once in a while - as long as core CG members know to keep an eye out that's not necessarily a huge problem. I dunno, politics complicates stuff. And patenting open-web stuff to me seems wrong on any number of levels. CGs actually have very little patent obligation compared to W3C Working Groups, so Apple has lighter weight approval for those than for WGs. Perhaps Google could consider the same thing. I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. - Maciej
Re: [whatwg] Defaulting new image solution to 192dpi
On May 17, 2012, at 12:20 PM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith jer...@adactio.com wrote: Kornel wrote: Note that the scale multiplier can be omitted already when only the size is specified I'm confused by what you mean by scale multiplier. The x value describes the pixel density of the device/screen, not the image, right? I think it only makes sense if it describes the image, so that: img srcset=100x100image-pixels.jpg 2x would display at 50x50px (CSS px). That is indeed how it works. Cheers, Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On May 16, 2012, at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 16, 2012 at 1:59 PM, Anne van Kesteren ann...@annevk.nl wrote: I just wanted to correct one small thing here. On Wed, May 16, 2012 at 10:51 PM, Jonas Sicking jo...@sicking.cc wrote: (The difference that the w3c lists were private is not really a meaningful difference if we're telling people to join CGs and do development there). We have not done that, but unfortunately nobody called out the bad suggestion either :-( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html I'm not sure what you think it's a bad suggestion? I would say that the CG was more successful in attracting author feedback than WhatWG currently is. The downside of the CG as executed is that it was much less successful in attracting browser implementor feedback (in part because it was apparently not advertised in places frequented by browser standards people). So the implementor feedback only got applied later, and without full knowledge and understanding of the CGs efforts. It's not useful to have a standards process that doesn't include all the essential stakeholders. The most important point though is that no one from the WHATWG recommended creating a CG. Saying that the existence of the CG obligates people to respond there is not really scalable, the logical conclusion would be that HTML standards discussion has to be spread among all future newly created groups that try to do anything HTML-related, even ones not advertised in the existing places. I don't see how that is a reasonable policy. It would be like if I made my own mozilla-feature-planning list and then got mad at Mozilla folks for not replying there when making release plans. Regards, Maciej
Re: [whatwg] Features for responsive Web design
On May 16, 2012, at 9:39 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, May 16, 2012 at 10:55 PM, Matthew Wilcox m...@matthewwilcox.com wrote: Chalk me up as another making that mistake. Properties on elements usually describe a property of the element. Not a property of something else (like the viewport). If it does indeed rely on a rendering issue (like the size of the viewport), wouldn't it make more sense to make it a CSS feature? I think that would be less confusing and follow better the established separation of layout in html, styling(/rendering) in CSS. CSS can handle this fine for presentational images (such as CSS background images). But it's not obvious that it's the best way to influence selection of content images references from img. Content images are meaningful, not just stylistic, so their variants are meaningful too (even if the choice of variant is influenced by presentational issues). Cheers, Maciej
Re: [whatwg] Features for responsive Web design
On May 15, 2012, at 8:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 15, 2012 at 9:28 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: 3.125x isn't particularly difficult to specify. I actually didn't even realize that 300dpi is 3.125 times 96dpi. Regardless, I think being able to specify 300dpi is easier than using a calculator. On the other hand, checking for an integer X factor is easier than checking for an integer multiple of 96dpi, for authors who would like to avoid the ugly visual artifacts of non-integral scaling. Which I hope is all of them. It's easier to tell that 3.125x is a bad idea than with 300dpi. Regards, Maciej
Re: [whatwg] picture, `img set`, and polyfills
On May 14, 2012, at 4:17 PM, Mathew Marquis m...@matmarquis.com wrote: It’s worth noting that a practical polyfill may not be possible when using `img set`, for reasons detailed at length elsewhere: http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ http://www.netmagazine.com/features/state-responsive-images Long story short: attempting to write a polyfill for `img set` leaves us in the exact situation we were in while trying to solve the issue of responsive images strictly on the front-end. We would be saddling users with a redundant download—first for the original src, then for the appropriately-sized source if needed. Interesting data point. Can you explain why this is the case for the img srcset syntax, but not for the picture syntax with an embedded img? I wasn't able to figure that out, from the articles you linked. Regards, Maciej
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 12, 2012, at 5:33 PM, Mathew Marquis m...@matmarquis.com wrote: I worry that, when faced with this markup, developers will simply opt to serve the largest possible image in a src. In fairness, that approach works with far less headache. For the resolution-adaptation use case, that wouldn't do the right thing by itself because it wouldn't downscale. img src=foo.jpg srcset=foo-highres.jpg 2x is the minimum you need to get proper fallback. When/if all browsers support srcset (assuming it is even selected), you could omit the src containing the 1x image and this would be a perfectly valid choice. The key issue here, and a big difference from the picture approach, is that to actually get higher resolution on a high-rez display, you need to rescale the image to below its normal intrinsic size. You can do this by explicitly styling it to a fixed size, by using an explicit image resolution, or through the 2x shorthand as above. But for compatibility reasons it can't just happen automatically or images meant to be viewed at 1x will be too small. Regards, Maciej
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year. To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic. The key to making the case for the picture element or something like it is to cite use cases. Most of the comments on that blog post just give opinions, without use cases backing them up. A lot more weight will be placed on explanations of *why* developers love something (e.g. it lets them do X where they otherwise couldn't, it lets them do Y more easily, etc) than just testimonials that they love it. Regards, Maciej P.S. Your examples in that blog post are not equivalent. Here are two examples that I believe would be equivalent for resolution adaptation only, presuming a 600x200 image and a 1200x400 scaled version: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px id=catface_picture alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture Other than more general verbosity, there are a few other other differences that show up: 1) The picture version has to repeat the alt text. 2) The picture version has to repeat the URL to the 1x asset. 3) The picture version has to explicitly set a width and height, because it does not have the built-in scaling semantics of srcset and so cannot rely on intrinsic size, since it will end up different between the two images. 4) The picture version has to use a specific order, while in the srcset version, order doesn't matter.
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 12, 2012, at 12:35 PM, Adam Barth w...@adambarth.com wrote: On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote: On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year. To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic. The key to making the case for the picture element or something like it is to cite use cases. Most of the comments on that blog post just give opinions, without use cases backing them up. A lot more weight will be placed on explanations of *why* developers love something (e.g. it lets them do X where they otherwise couldn't, it lets them do Y more easily, etc) than just testimonials that they love it. Regards, Maciej P.S. Your examples in that blog post are not equivalent. Here are two examples that I believe would be equivalent for resolution adaptation only, presuming a 600x200 image and a 1200x400 scaled version: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px id=catface_picture alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture Other than more general verbosity, there are a few other other differences that show up: 1) The picture version has to repeat the alt text. 2) The picture version has to repeat the URL to the 1x asset. 3) The picture version has to explicitly set a width and height, because it does not have the built-in scaling semantics of srcset and so cannot rely on intrinsic size, since it will end up different between the two images. 4) The picture version has to use a specific order, while in the srcset version, order doesn't matter. Does the id=catface_picture attribute play an essential role in this example, or is it just extra clutter in the picture example? Extra clutter. I forgot to delete it after I switched that example from using externally declared style to a style attribute. Corrected versions: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 6:24 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: That all said, I don't like the 2x notation. It's declaring this image's resolution is twice that of a normal image. This has two problems. For one, we already have a unit that means that - the dppx unit. Using 2dppx is identical to the meaning of 2x. Since image-set() is newer than the dppx unit, we should change it to use resolution instead. dppx has the downside that not even CSS Working Group members can consistently spell it correctly. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 6:47 AM, Simon Pieters sim...@opera.com wrote: On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: For two, I'm not sure that it's particularly obvious that when you say 2x, you should make sure your image was saved as 196dpi. You have to already know what the default resolution is. As well, I think that values like 300dpi are pretty common, and they don't map to integral 'x' values. If people say screw it and use 3x, this'll be slightly wrong and I think will cause ugly blurring. If we make this take resolution, people can just use the dpi unit. Can we just use CSS's 'dpi' instead? img src=default.jpg srcset=highres.jpg 300dpi CSS's 'dpi' is confusing, because it actually defines the ratio of device pixels to CSS inches, not device pixels to physical inches, as most users would expect 'dpi' to mean in the context of a graphics program. So 300dpi would mean the same thing as 3.125x, and would likely itself result in ugly blurring, since scaling by a fractional scale factor rarely looks crisp. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 7:26 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/10/12 10:19 AM, Mathew Marquis wrote: Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option. Why not? In any case, _DNS_ prefetching would be the same for both the low-res and high-res image, I would think. The original src would be fetched in any case, saddling users with a redundant download. That sounds like image prefetching, not DNS prefetching. I see no obvious reason it couldn't look at multiple attributes. Indeed. I'm reasonably familiar with WebKit's preloading code and I see no reason it couldn't look at the srcset attribute. This would work fine for scale factor selection. Unfortunately, it would not work for the suggestion to have srcset pick images to fit available space based on width and height. Available space is not known until layout time, which happens too late for preloading decisions. So width/height fitting would defeat prefetch, regardless of specific syntax used. Perhaps this is what the Chrome engineers were thinking of; hard to say without more detail. Regards, Maciej
Re: [whatwg] Proposal in supporting the writing of Arabizi
On May 10, 2012, at 12:00 PM, Sami Eljabali seljab...@gmail.com wrote: Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Mac OS X supports Arabic, Arabic - PC and Arabic - QWERTY input methods. If none of these provide the functionality of Arabizi then please file a bug at http://bugreport.apple.com/ and we can consider adding it for the whole OS. Mac OS X also supports third-party downloadable input methods. We are unlikely to support a browser-specific form of input methods. Regards, Maciej
Re: [whatwg] Request for new DOM property textarea.selectionText
Does this work in any non-WebKit browsers? (Asking mainly out of curiosity; I
would tend to agree in any case that adding nontrivial editing APIs that are
specific to only plaintext editable controls is not a good idea. But it might
be nice to specify explicitly whether execCommand works on form controls.)
While I would not go out of my way to praise execCommand, setRangeText is also
not a very good API design:
1) setRangeText is a vague and confusing name. If its only function was
replacing the selection, then replaceSelection would be much better, but:
2) The method is overloaded to do a variety of tangentially related things. The
overloading makes it hard to give it a good name. If the different operations
were different methods, it would be easier to name it well (replaceSelection,
replaceRange), but it's hard to describe all four of the selection modes.
3) It's not clear that all of the different selection modes of this function
have use cases.
Regards,
Maciej
On Apr 27, 2012, at 9:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
Why are we adding this new API? WebKit already supports
document.execCommand('InsertText', false, new selected text);
- Ryosuke
On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 10 May 2010, Biju wrote:
Can we have a new DOM property textarea.selectionText which can be used
to set/get selection text of a TEXTAREA/INPUT type=text.
Gettng the value is relatively easy:
On Mon, 10 May 2010, Biju wrote:
Current way in firefox is to
1. OrigStart = textarea.selectionStart
But admittedly setting it is a pain:
2. textarea.value = textarea.value.substr(0, OrigStart)
+ new_text_to_replace
+ textarea.value.substr(textarea.selectionEnd);
3. Now u loose original selection, so
4. textarea.setSelectionRange(OrigStart,
OrigStart+new_text_to_replace.length)
5. remember .scrollTop and reapply if needed
I agree that making this easier would be good.
On IE even though wierd you can do it simply by
document.selection.createRange().text = new_text_to_replace;
BTW, you need to make sure the selection is currently on the
textarea/input form control.
IE is also very fast when doing that, when firefox hangs few second
using the other way
IE's version is non-standard and not adopted by other UAs.
On Mon, 10 May 2010, Ojan Vafai wrote:
In addition to selection and scroll issues, needing to replace the
entire textarea value doesn't scale and thus limits what sorts of things
you can do with textareas. A general way to set a sub-part of a
textarea's value seems useful to me. I don't think we should tie that to
setting the selected text though.
textarea.setRangeText(start, end, text);
It replaces the text between start and end, maintains current scroll
position and preserves the selection.
On Tue, 11 May 2010, Biju wrote:
Both have advantages
Option 1 (textobj.selectionText) advantages
* No need for web developer to provide selection start/end
* Automatically select the newly inserted text,
(as most time that is what you want)
* No need for web developer to calculate selection start/end for
setting it after text insert
* preserve scroll
* Has both Getter and Setter
Option 2 (textobj.setRangeText(start, end, text)); advantages
* Independent of selection, web developer can change text at any range
with out affecting selection
* Web developer has more options with it.
* preserve scroll
So I want to merge both suggestion, with a new signature,
also trying to reduce coding for web developer less code less bug
textobj.setRangeText(newtext, start, end, cursorpos)
parameters:
newtext
- optional parameter
- new text that will replace existing
- if missing/null/undefined/NaN then default to
start
- optional parameter
- starting position of the original textobj text that need to be
replaced
- if missing/null/undefined/NaN then default to textobj.selectionStart
- negative value make start position from last character in the text
content
end
- optional parameter
- ending position of the original textobj text that need to be replaced
- if missing/null/undefined/NaN then default to textobj.selectionEnd
- negative value make end position from last character
cursorpos
- optional parameter
- if missing/null/undefined/NaN then default to 0
- what should happen to cursor/selection after text insert, its values
are
- - 0 - select the newly inserted text
- - 1 - place cursor at beginning of inserted text
- - 2 - place cursor at the end of inserted text
- - 3 - keep selection unaffected
* issue, when value is 3 what should we do when setRangeText is
replacing text
which has some parts selected and some other parts unselected
so if somebody want replace selection text it is just
textobj.setRangeText(newtext);
which is almost same as my original proposal, and
Re: [whatwg] Request for new DOM property textarea.selectionText
On Apr 29, 2012, at 1:41 PM, David Young dyo...@pobox.com wrote: On Sun, Apr 29, 2012 at 10:38:26AM +0300, Aryeh Gregor wrote: On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa rn...@webkit.org wrote: That sounds like a tangential issue. We can easily extend execCommand to support arbitrary range(s) since such a feature is also valuable in richly editable areas. Ranges don't exist in plaintext areas. How would you get a Range object that selects text in a textarea? That's why we have separate .selectionStart, .selectionEnd, etc. properties to start with. When you say that ranges do not exist in plaintext areas (not quite sure what plaintext means in this context), is that for some reason, or is it just a historical artifact? Aryeh is referring to the DOM Range interface, which can only apply to nodes that are directly in the DOM, and offsets into their text. The text contents of an input or textarea are not properly in the DOM, so you cannot use a DOM Range to reference such ranges. I am no sure this is what Ryosuke had in mind though; I think he just meant that in general we could support some notion of a range, and presumably we could come up with one that applies to contentEditable/designMode as well as to text controls. One extreme possibility is to simply change the definition of Range to allow it to address the contents of text input controls. Regards, Maciej
Re: [whatwg] Footer inside header
On Apr 26, 2012, at 9:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 26, 2012 at 1:32 AM, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On Apr 25, 2012 9:20 PM, Andrés Sanhueza peroyomasli...@gmail.com wrote: I see no reason a footer as in textual metadata of a section can't be inside a header (lead of a section). Could this be considered to be allowed? Do you have a real example where you think that markup would be useful? If user agents provide commands to navigate to headers and footers, nesting them could make navigation confusing. One was presented in another thread - according to the definition of footer, it appears that authorship information is most appropriate to put there. But sometimes the byline is placed inside the header area, which is reasonably marked up with a header. So, it makes sense to be able to nest the footer within the header. It may be useful to have distinctive markup to identify a byline within a header. But placing a footer element inside a header element does not seem like the most clear way to do that. I expect most authors would not think to use it that way, and content consumers would have a hard time distinguishing intentional cases of such use from authoring errors. Regards, Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 22, 2012, at 7:10 PM, Glenn Maynard wrote: On Sun, Apr 22, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote: All JavaScript that runs on the main thread has the potential to freeze the UI for all pages sharing that thread. APIs on the main thread are designed to allow developers to avoid doing just that. If the *only* way to do something has that potential, then it's a bug in the API. Some feel that a call that reads from the GPU may also be in this category of intrinsically too slow/unpredictable. However, we are talking about operations with a much lower upper bound on their execution time. If the reasonable upper bound is high enough to cause visible UI degradation, and an asynchronous API can prevent that, then it needs an asynchronous API. If adding an async version has not been an emergency so far, then I don't think it is critical enough to block adding scaled backing store support. I hope we doesn't need an emergency to fix problems. Nobody's proposing blocking anything, just providing a better API. This doesn't impose any requirements on implementations who don't need it; it just makes it possible for those who do. Those who don't can always block and queue the callback to happen as soon as the script returns to the event loop--doing it better is just QoI. For the record, I don't object to adding an async version of getImageData, or some alternate means of getting async behavior. I would, however, object to: - Removing the existing synchronous getImageData (too much compatibility impact at this point) - Forcing getImageDataHD to only offer an async variant, despite synchronous getImageData existing probably indefinitely At least the latter has been advocated previously on this thread. It's not clear to me what you are personally advocating, so I cannot tell if I disagree with you. Regards, Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 20, 2012, at 6:53 AM, Glenn Maynard wrote: On Thu, Apr 19, 2012 at 11:28 PM, Maciej Stachowiak m...@apple.com wrote: You could also address this by adding a way to be notified when the contents of an ImageData are available without blocking. That would work with both vanilla getImageData and the proposed getImageDataHD. It would also give the author the alternative of just blocking (e.g. if they know the buffer is small) or of sending the data off to a worker for processing. This would result in people writing poor code, based on incorrect assumptions. It doesn't matter how big the buffer is; all that matters is how long the drawing calls before the getImageData take. For example, if multiple canvases are being drawn to (eg. on other pages running in the same thread), they may share a single drawing queue. Any time you retrieve image data synchronously, and it happens to require a draw flush, you freeze the UI for all pages sharing that thread. Why is that okay for people to do? We should know better by now than to expose APIs that encourage people to block the UI thread, after spending so much time trying to fix that mistake in early APIs. (This should expose a synchronous API in workers if and when Canvas makes it there, of course, just like all other APIs.) All JavaScript that runs on the main thread has the potential to freeze the UI for all pages sharing that thread. One can imagine models that avoid this by design - for example, running all JavaScript on one or more threads separate from the UI thread. But from where we are today, it's not practical to apply such a solution. It's also not practical to make every API asynchronous - it's just too hard to code that way. In light of this, we need some sort of rule for what types of APIs should only be offered in asynchronous form on the main thread. Among the major browser vendors, there seems to be a consensus that this should at least include APIs that do any network or disk I/O. Network and disk are slow enough and unpredictable enough that an author could never correctly judge that it's safe to do synchronous I/O. Some feel that a call that reads from the GPU may also be in this category of intrinsically too slow/unpredictable. However, we are talking about operations with a much lower upper bound on their execution time. We're also talking about an operation that has existed in its synchronous form (getImageData) for several years, and we don't have evidence of the types of severe problems that, for instance, synchronous XHR has been known to cause. Indeed, the amount of trouble caused is low enough that no one has yet proposed or implemented an async version of this API. If adding an async version has not been an emergency so far, then I don't think it is critical enough to block adding scaled backing store support. Nor am I convinced that we need to deprecate or phase out the synchronous version. Perhaps future evidence will change the picture, but that's how it looks to me so far. Regards, Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 17, 2012, at 3:32 PM, Darin Fisher wrote: ^^^ This got me thinking... In Chrome at least, getImageData() doesn't actually block to fetch pixels. The thread is only blocked when the first dereference of the pixel buffer occurs. I believe this is done so that a getImageData() followed by putImageData() call will not need to block the calling thread. The above suggests that making getImageData() asynchronous would not actually provide any benefit for cases where the page does not dereference the pixel buffer. Another use case where this comes up is passing the ImageData to a web worker. If the web worker is the first to dereference the ImageData, then only the web worker thread should block. I think this becomes an argument for keeping getImageData() as is. It assumes that ImageData is just a handle, and we could find another way to discourage dereferencing the pixel buffer on the UI thread. Hmm... You could also address this by adding a way to be notified when the contents of an ImageData are available without blocking. That would work with both vanilla getImageData and the proposed getImageDataHD. It would also give the author the alternative of just blocking (e.g. if they know the buffer is small) or of sending the data off to a worker for processing. Regards, Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal version
of window.confirm() or window.alert(). Dialogs that are fully in-page
Oops, got cut off here. What I meant to say is something like dialogs that
are fully in-page are the emerging standard for high-quality page-modal
prompting.
Non-blocking window.{alert,confirm,prompt} would most likely be rendered by
UAs as in-page overlays / tab-scoped dialogs. This is what we would do in
Chrome, and it seems like others would do the same given the prevalence of
the standard window.{alert,confirm,prompt} being implemented in a tab-scoped
manner already by some browsers (albeit with bugs).
I think people use alert, confirm and prompt in part because they are so easy
to use. People who choose window.{alert,confirm,prompt} probably don't care
about loss of customization or else they would roll their own dialogs.
Why not provide less sucky versions of those common dialogs?
Benefit: Less code for simple dialogs.
Con: Another web platform API to standardize.
Con: Encourages poor HI design (since these stock dialogs should almost never
be used).
That being said, I find in-page UI less objectionable than a pop-up alert, but
in that case I'm not sure it makes sense to overload the existing API. It would
be better to make new methods so feature testing is possible. Even given all
that, I'm not confident of the value add over dialog.
Regards,
Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. Would the async version still require a flush and immediate readback if you do any drawing after the get call but before the data is returned? Regards, Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal version
of window.confirm() or window.alert(). Dialogs that are fully in-page
Oops, got cut off here. What I meant to say is something like dialogs that
are fully in-page are the emerging standard for high-quality page-modal
prompting.
Non-blocking window.{alert,confirm,prompt} would most likely be rendered by
UAs as in-page overlays / tab-scoped dialogs. This is what we would do in
Chrome, and it seems like others would do the same given the prevalence of
the standard window.{alert,confirm,prompt} being implemented in a tab-scoped
manner already by some browsers (albeit with bugs).
I think people use alert, confirm and prompt in part because they are so
easy to use. People who choose window.{alert,confirm,prompt} probably don't
care about loss of customization or else they would roll their own dialogs.
Why not provide less sucky versions of those common dialogs?
Benefit: Less code for simple dialogs.
Con: Another web platform API to standardize.
Con: Encourages poor HI design (since these stock dialogs should almost never
be used).
That being said, I find in-page UI less objectionable than a pop-up alert,
but in that case I'm not sure it makes sense to overload the existing API. It
would be better to make new methods so feature testing is possible. Even
given all that, I'm not confident of the value add over dialog.
It seems like poor HI design is rather subjective. Some might prefer the
OS-native look-and-feel of these simple dialogs.
The APIs as they currently exist are unable to provide an experience that is
consistent with Mac OS X or iOS HI design. Modal alerts are rarely used in
general, and when they are used, the buttons need to have labels that conform
to the action rather than generic labels like OK. I feel that the original
design of alert(), confirm() and prompt() is very Windows-centric, and really
Windows-circa-late-90s-centric.
You could enhance the API to make these dialogs sufficiently more customizable.
But then I am even more skeptical of the value over dialog.
Good point about feature testing. I'd be OK with async{Alert,Confirm,Prompt}
or whatever name variant we prefer.
You don't see much value in the simplicity of having these methods be
provided by the platform? It seems like dialog requires much more code to
setup.
I think there's almost 0 times that it is correct to pop up an OK/Cancel
dialog. If you incorporate customizing the button labels, I don't think
dialog is materially more complicated.
Regards,
Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 20, 2012, at 3:50 PM, Adam Barth wrote:
On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 19 Mar 2012, Jochen Eisinger wrote:
I'd like to put forward a proposal for extending the modal prompts
(alert/confirm/prompt) with an optional callback parameter. If the
optional callback parameter is present, the javascript execution would
resume immediately. The callback will be invoked when the dialog that
doesn't need to be browser modal now, is closed.
I wouldn't add such a callback to showModalDialog, as I think sites can
use e.g. window.open instead.
I've written up the proposal here:
http://wiki.whatwg.org/wiki/Modal_prompts
The motivation for this is that in a tabbed browser, modal dialogs are
potentially disrupting the work flow of the user as they can't interact
with any other web site as long as the modal dialog is displayed.
Current browsers are having problems with the modal prompts:
Chromium for example doesn't display a window created by showModalDialog
in a modal way: http://crbug.com/16045
WebKit and Firefox don't suppress events while a modal dialog is
running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
https://bugzilla.mozilla.org/show_bug.cgi?id=360872
Firefox displays modal prompts as tab-modal. However, it's possible to
execute JavaScript in a tab that should be blocked by a modal prompt:
https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from
separate tabs can block each other:
https://bugzilla.mozilla.org/show_bug.cgi?id=727801
Feedback on this proposal would be highly appreciated!
Moving forward, I think the dialog element that we'll soon be adding is
probably a better direction to go in.
http://wiki.whatwg.org/wiki/Dialogs#Proposal
I'm not sure dialog addresses the same use cases as alert() and
confirm() because dialog is significantly more complicated.
== Non-modal confirm() ==
script
[...]
confirm(Are you sure you want to order the widget?, function(result) {
if (result)
sendOrder();
else
cancelOrder();
});
/script
== dialog ==
dialog id=orderConfirm
Are you sure you want to order the widget?
button
onclick=document.getElementById('orderConfirm').close(true);Ok/button
button
onclick=document.getElementById('orderConfirm').close(false);Cancel/button
/dialog
script
[...]
var dialog = document.getElementById('orderConfirm');
dialog.addEventListener('close', function() {
if (dialog.returnValue == true)
sendOrder();
else
cancelOrder();
}, false);
dialog.showModal();
/script
Even after all that, you get a less functional experience in some
respects. For example, on Mac OS X, the Cancel button should be to
the left of the Ok button whereas on Windows they should be ordered as
in my example (i.e., with Ok to the left of Cancel). I'm sure there's
some way to elaborate the sample code further to fix that bug, but I
think you get the point.
dialog will give a better user experience than even a non-modal version of
window.confirm() or window.alert(). Dialogs that are fully in-page
alert() is mostly only used by either by sites with a low-quality user
experience, or as as non-production debugging aid. In both cases, authors who
care about the user experience will use dialog or a JS-implemented lightbox
style dialog. And authors who do not care about user experience, or who are
doing a quick debugging hack in non-production code, will use old-fashioned
blocking alert/confirm/prompt. Thus, I am not sure there is really a meaningful
audience for the non-blocking editions of these calls.
Regards,
Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: dialog will give a better user experience than even a non-modal version of window.confirm() or window.alert(). Dialogs that are fully in-page Oops, got cut off here. What I meant to say is something like dialogs that are fully in-page are the emerging standard for high-quality page-modal prompting. I should add that this could be partly for path-dependent reasons, and that if other technologies had been available, authors might not have resorted to in-page modality with overlays. But I think the key missing enabled was not asynchrony but rather the ability to fully control the UI, layout and available commands of the modal experience. alert() is mostly only used by either by sites with a low-quality user experience, or as as non-production debugging aid. In both cases, authors who care about the user experience will use dialog or a JS-implemented lightbox style dialog. And authors who do not care about user experience, or who are doing a quick debugging hack in non-production code, will use old-fashioned blocking alert/confirm/prompt. Thus, I am not sure there is really a meaningful audience for the non-blocking editions of these calls. Regards, Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 20, 2012, at 6:04 PM, Boris Zbarsky wrote:
On 3/20/12 6:50 PM, Adam Barth wrote:
I'm not suredialog addresses the same use cases as alert() and
confirm() becausedialog is significantly more complicated.
But also allows for much better UX...
dialog id=orderConfirm
Are you sure you want to order the widget?
button
onclick=document.getElementById('orderConfirm').close(true);Ok/button
button
onclick=document.getElementById('orderConfirm').close(false);Cancel/button
Those should be Yes and No respectively, according to every single HIG
I've seen. Something that's not possible with confirm(), unfortunately.
Mac OS X HIG recommends that the active option should be labeled with a
meaningful verb or verb phrase, not just something generic like OK or Yes.
So the proper labels would be Order and Cancel in this example.
reddit's login overlay, for example, actually meets the spirit of this
requirement by having create account, login and close this window as the
available commands, though the layout is webby and consistent with the web app
itself, rather than consistent with Mac UI conventions.
Regards,
Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote: On Mar 20, 2012, at 3:05 PM, Edward O'Connor eocon...@apple.com wrote: Charles Pritchard wrote: But now run through this logic when the canvas is making a high res backing store automatically: by doing the clever thing, you're now quadrupling the size of the canvas, and you're paying an exorbitant storage cost for doing so. Which (a): never happens Sorry, what never happens? The backing store itself is never set by 2x in the implementation. Not in any public implementations I've seen. It's always 1:1 with height and width units. We're considering the possibility of scaling the backing store in future releases (which we can't really discuss in detail). We have experimented with it in WebKit, and we believe it's not viable to ship a production browser with backing store scaling without the sorts of API changes that Ted proposed because of how much content breaks. An automatically scaled backing store is better for authors, because for the case where they are not doing any direct pixel manipulation, they get higher quality visual results with no code changes on devices that scale CSS pixels. But to offer it, we need to take care of the compatibility issues, and also provide a path for authors who have gone the extra mile to hand-scale 1x backing stores on 2x devices. In other words, all the following cases need to work: devicePixelRatio is 1; backingStorePixelRatio is 1. devicePixelRatio is 2; backingStorePixelRatio is 1. devicePixelRatio is 2; backingStorePixelRatio is 2. Maybe even other possibilities. In other words, we don't want to force either the assumption that backingStorePixelRatio is always 1, or that it is always is equal to devicePixelRatio. We believe that in time, neither is a safe assumption. Regards, Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are currently difficult or impossible.
Neat idea to offer async backing store access. I'm not sure that we should tie
this to backing store access at true backing store resolution vs at CSS pixel
nominal resolution, because it will significantly raise the barrier to authors
recoding their existing apps to take full advantage of higher resolutions. With
Ted's proposal, all they would have to do is use the HD versions of calls and
change their loops to read the bounds from the ImageData object instead of
assuming. If we also forced the new calls to be async, then more extensive
changes would be required.
I hear you on the benefits of async calls, but I think it would be better to
sell authors on their benefits separately.
Cheers,
Maciej
- James
On Mar 20, 2012 10:29 AM, Edward Oapos;Connor eocon...@apple.com wrote:
Hi,
Unfortunately, lots of canvas content (especially content which calls
{create,get,put}ImageData methods) assumes that the canvas's backing
store pixels correspond 1:1 to CSS pixels, even though the spec has been
written to allow for the backing store to be at a different scale
factor.
Especially problematic is that developers have to round trip image data
through a canvas in order to detect that a different scale factor is
being used.
I'd like to propose the addition of a backingStorePixelRatio property to
the 2D context object. Just as window.devicePixelRatio expresses the
ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would
express the ratio of backing store pixels to CSS pixels. This allows
developers to easily branch to handle different backing store scale
factors.
Additionally, I think the existing {create,get,put}ImageData API needs
to be defined to be in terms of CSS pixels, since that's what existing
content assumes. I propose the addition of a new set of methods for
working directly with backing store image data. (New methods are easier
to feature detect than adding optional arguments to the existing
methods.) At the moment I'm calling these {create,get,put}ImageDataHD,
but I'm not wedded to the names. (Nor do I want to bikeshed them.)
Thanks for your consideration,
Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 21, 2012, at 8:31 PM, Charles Pritchard wrote:
On 3/21/2012 8:21 PM, Maciej Stachowiak wrote:
On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote:
On Mar 20, 2012, at 3:05 PM, Edward O'Connoreocon...@apple.com wrote:
Charles Pritchard wrote:
But now run through this logic when thecanvas is making a high res
backing store automatically: by doing the clever thing, you're now
quadrupling the size of the canvas, and you're paying an exorbitant
storage cost for doing so.
Which (a): never happens
Sorry, what never happens?
The backing store itself is never set by 2x in the implementation. Not in
any public implementations I've seen. It's always 1:1 with height and width
units.
We're considering the possibility of scaling the backing store in future
releases (which we can't really discuss in detail). We have experimented
with it in WebKit, and we believe it's not viable to ship a production
browser with backing store scaling without the sorts of API changes that Ted
proposed because of how much content breaks.
The change being the addition of a backingStorePixelRatio or the change
being the addition of a second set of HD items?
We think both those changes are required to handle all cases gracefully.
I get what you're saying about HD; if the user requests a non-HD, it'd return
a typical 1:1 backing store, which most sites expect.
Still, it seems a bit weird.
Why not use the method that already exists of managing the CSS and
devicePixelRatio? If an author is using new methods,
they're certainly able to use the old ones.
I'm not sure what you mean by that. As I mentioned, backingStorePixelRatio is
in general not equal to devicePixelRatio. It's true that you might be able to
infer the backing store scale by creating a canvas solely for testing, but that
is needlessly awkward.
An automatically scaled backing store is better for authors, because for the
case where they are not doing any direct pixel manipulation, they get higher
quality visual results with no code changes on devices that scale CSS
pixels. But to offer it, we need to take care of the compatibility issues,
and also provide a path for authors who have gone the extra mile to
hand-scale 1x backing stores on 2x devices. In other words, all the
following cases need to work:
devicePixelRatio is 1; backingStorePixelRatio is 1.
devicePixelRatio is 2; backingStorePixelRatio is 1.
devicePixelRatio is 2; backingStorePixelRatio is 2.
Maybe even other possibilities. In other words, we don't want to force
either the assumption that backingStorePixelRatio is always 1, or that it is
always is equal to devicePixelRatio. We believe that in time, neither is a
safe assumption.
Well if they --need-- to work, better to add the value sooner than later.
My concern is that you've also got window.screen.logicalXPixelRatio on the
desktop.
You'll really have three items now to add up.
devicePixelRatio * backingStorePixelRatio * logicalPixelRatio.
Is that middle item really necessary?
I wasn't able to get anyone to budge on changing window.devicePixelRatio on
the desktop. It's fixed at 1.
I was unable to decipher what IE's logical{X,Y}DPI does and how it differs from
device{X,Y}DPI and for that matter system{X,Y}DPI. But I don't believe any of
those things relate to the canvas backing store, however, so I don't see how
they eliminate the need for backingStoreRatio.
Regards,
Maciej
[whatwg] Meta Referrer
Hi Folks, What is the plan (if any) for turning Meta Referrer into a standard? Currently there's a wiki spec, which is somewhat incomplete and which modifies the middle of the HTML Fetch algorithm (probably not a future-proof approach, since it refers to a numbered step): http://wiki.whatwg.org/wiki/Meta_referrer It's in the meta extension registry as a proposal that doesn't meet requirements for registration: http://wiki.whatwg.org/wiki/MetaExtensions Is there any plan to propose this for inclusion in HTML, or else write a standalone spec that is sufficiently detailed for interoperable implementations? What do other browser vendors think of the existing proposal? Do folks plan to implement this as-is? Regards, Maciej
Re: [whatwg] Full Screen API Feedback
On May 13, 2011, at 12:46 AM, Henri Sivonen wrote: On Thu, 2011-05-12 at 20:29 -0400, Aryeh Gregor wrote: In particular, Flash has allowed this for years, with 95%+ penetration rates, so we should already have a good idea of how this feature can be exploited in practice. I don't know of exploits in the wild, but I've read about proof-of-concept exploits that overwhelmed the user's attention visually so that the user didn't notice the Press ESC to exit full screen message. This allowed subsequent UI spoofing. (I was unable to find the citation for this.) Unfortunately, trying to mitigate this problem without explicit per-origin permission management means that the browser would need to take over the whole screen to show a warning for a few moments in such a way that during that time the site has no way to show its own distractions. That would be very annoying on legitimate sites. (With my user hat on, I'm already annoyed by the Press ESC to exit full screen in the Flash mode of YouTube.) Also, it would be less aesthetically pleasing than having a part of the page animate to zoom to full screen. Limiting keyboard entry to arrow keys, space and such nontextual input mitigates the impact of UI spoofing attacks somewhat. However, for full-screen games, it might be useful to be able to request more keyboard input (as mentioned in the proposal). It would be good to keep in mind that the API needs to support requesting keyboard permissions, and it might be considered odd to have totally different API flows for the keyboard-enabled case and for the keyboard-limited case. If full-screen is limited to being initiated by a user event, and has a visible transition, that significantly diminishes the possibility of effective spoofing. I would say it is better to entirely disallow non-user-initiated fullscreen than to prompt about it. Limited or no keyboard input also greatly mitigates the risk of a full OS UI spoofing attack. I think there are better ways to address this than prompting the user. For example, for apps requesting full keyboard access, there could be an always-visible onscreen indicator that is not easily covered up. This does not necessarily have to be ugly, or distracting in a game context. Another possibility is to have the indicator appear on mouse move. I think these are more sensible and pleasant mitigations than a user prompt. And possibly also more effective. If the user can be confused about what state the OS is in after clicking something and then seeing a visible transition (perhaps followed by a faked version of the browser crashing and the OS popping up some password dialog), then they could quite possibly also be fooled if they first clicked on a cancel or allow prompt. Note that for the non-keyboard / limited keyboard case (likely the common case for video players), the full-OS spoof phishing attack is not even much of a threat in the first place, so prompting in that case just promotes confirmation fatigue with no real benefit. If we could take prompting the user off the table in the range of UIs we are considering, it would allow us to significantly simplify both the API and the user interface for this feature. So I hope we can consider this. I'm not sure extensions like NoScript alone are sufficient reason to impose the additional complexity required by a user prompting model. After all, the API for running a script doesn't involve an asynchronous request model, yet NoScript somehow manages to do its thing. Regards, Maciej
Re: [whatwg] Can we make checkboxes readonly?
On Apr 6, 2011, at 3:46 PM, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-04-07 00:28, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. That's true, but if the controls are readonly, then the user can't change the value and so why does that matter? Could you clarify the use case for having a readonly checkbox value submitted? An app may dynamically set inputs or groups of inputs to readonly based on app state. When you submit, though, it's impossible to tell (without hacks) whether a checkbox was checked-but-disabled or just unchecked. Handling the form data is *much* easier if you just get all the data, regardless of whether, as a UI convenience, your app temporarily set some of the inputs to readonly. In native app UI, it's highly unusual to have a checkbox that is read-only but not disabled. It would be extremely confusing for a checkbox to have the enabled look but not actually be checkable. Therefore, we should not encourage content authors to build UI that looks like that. If you want to dynamically turn some inputs read-only but still submit their values, then presumably you are using script and can add hidden inputs to reflect that state. While this is inconvenient, I don't think it is a good idea to create bad UI solely for convenience. Another possibility is to make read-only checkboxes look and act disabled, with the only difference being whether the value is submitted or not. I have no objection in principle to such a state, but: - readonly seems like a poor name for this state, since in the case of text controls, readonly actually has different user-visible interaction behavior from disabled, not just different submission rules. - The fact that older browsers wouldn't support this special state makes it hard to adopt incrementally. disabled with an extra attribute saying submit anyway would do a better job of degrading gracefully, but would mean that for a while, authors have to do the hidden input trick as fallback anyway. Given these things and the relative obscurity of the use case (UIs where disabling and enabling controls follows a complex pattern are rare and typically not good design anyway), I am not sure the feature is worthwhile. Regards, Maciej
Re: [whatwg] documentFragment and innerHTML
WebKit already has insertAdjacentHTML support. On Feb 26, 2011, at 4:47 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Sat, Feb 26, 2011 at 9:52 AM, Rafael Holt r...@ratherodd.com wrote: Yes, I had just never heard of insertAdjacentHTML(), since it doesn't enjoy Webkit or Gecko support. Once it does though, I agree it's a nice addition. As for createContextualFragment(), it bring unnecessary complexity to this, having to mess about with ranges. Thanks for pointing out insertAdjacentHTML() - I'll keep an eye on its implementation progress. Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=613662 I didn't find a WebKit bug in a quick search.
Re: [whatwg] Proposal for a tab visibility API
On Dec 8, 2010, at 11:47 AM, Alex Komoroske wrote: Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature (http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. * A page wants to detect when it is moving into or out of the back-forward cache. This use case is already handled with events specific to the back/forward cache (pagehide and pageshow). That leaves the following use cases: * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A page wants to detect when it is being prerendered so it can behave appropriately. I am not sure what the third needs exactly, but it seems like first two could be better served with an API that sets a timer which will only fire when the page is visible. That kind of API might be easier to use right, and avoids the need for JS to run when switching tabs, just to cancel and restart timers. Also I wonder if pagehide and pageshow could be broadened to help the prerendering use case. It seems a bit speculative to make API just so Web pages can find out about an experimental feature being used. Regards, Maciej With these use-cases in mind, there are a number of requirements. ==Requirements== * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window * “prerender” : the tab is currently being loaded in an off-screen tab, and may never be shown to the user. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. In the future, the list of possible values may be extended. Of these states in this list, all except “visible” are considered to be hidden. Developers can use the existence of this property to know that they can rely on the rest of this API, too. =document.isVisible= A simple convenience read-only property that returns a boolean. Returns true if document.visibility’s current value is in the set of visibility states considered to be visible (for the first iteration of this API, that would only include the “visible” state). =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. Thoughts or comments are welcome. --Alex Komoroske
Re: [whatwg] Video with MIME type application/octet-stream
On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote: On Tue, 07 Sep 2010 11:51:55 +0200, And Clover and...@doxdesk.com wrote: On 09/07/2010 03:56 AM, Boris Zbarsky wrote: P.S. Sniffing is harder that you seem to think. It really is... Quite. It surprises and saddens me that anyone wants to argue for *more* sniffing, and even enshrining it in a web standard. IE9, Safari and Chrome ignore Content-Type in a video context and rely on sniffing. If you want Content-Type to be respected, convince the developers of those 3 browsers to change. If not, it's quite inevitable that Opera and Firefox will eventually have to follow. At least in the case of Safari, we initially added sniffing for the benefit of video types likely to be played with the QuickTime plugin - mainly .mov and various flavors of MPEG. It is common for these to be served with an incorrect MIME type. And we did not want to impose a high transition cost on content already being served via the QuickTime plugin. The QuickTime plugin may be a slightly less relevant consideration now than when we first thought about this, but at this point it is possible content has been migrated to video while still carrying broken MIME types. Ogg and WebM are probably not yet poisoned by a mass of unlabeled data. It might be possible to treat those types more strictly - i.e. only play Ogg or WebM when labeled as such, and not ever sniff content with those MIME types as anything else. In Safari's case this would have limited impact since a non-default codec plugin would need to be installed to play either Ogg or WebM. I'm also not sure it's sensible to have varying levels of strictness for different types. But it's an option, if we want to go there. Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Aug 31, 2010, at 4:16 PM, Kornel Lesiński wrote: On 31.08.2010, at 23:39, Tab Atkins Jr. wrote: At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Data URLs already provide this. What about existing UAs that implement data: URIs, but not sandbox? What about them? (Remember, the context of the use data urls suggestion was to solve the minority use-case of wanting to fill an iframe without a network request, without triggering sandboxing.) Yes, it's OK for data without sandboxing. However, inline data without sandboxing does not cover all use cases of srcdoc. There's another use case of inline data _with_ sandboxing and fallback for HTML4 UAs, for which data: URI currently cannot provide. My point is that data: URIs provide only half of srcdoc functionality, and if srcdoc is supposed to be dropped in favor of data: URI, then the other use case needs to be taken into account as well. You can use sandboxing with a data: URI by also specifying the sandbox attribute. As currently specified, srcdoc is almost entirely syntactic sugar. Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: While talking with the implementor of @srcdoc in Webkit, it came up that, though @srcdoc is *designed* for use with @sandbox, the author still has to explicitly add @sandbox to the iframe or else they don't get the sandbox security model. Can we make this automatic? Specifically, when iframe srcdoc=foo/iframe is specified (without @sandbox), it drops into the sandbox security model as if iframe sandbox srcdoc=foo/iframe was used. If @sandbox is explicitly added, its value is instead used, so the author can set the sandbox security flags if desired. This would mean that there is no way for an author to use @srcdoc *without* sandboxing. This appears to be a minority use-case in the first place (as far as I can tell, it's pretty much just useful for testing purposes), but the author can always use a data: url in that case. I think it's better to let these remain orthogonal features. In general I think it is a net negative to usability when Feature A implicitly turns on Feature B. Implicit relationships like this make the Web platform more confusing. Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote: On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak m...@apple.com wrote: I think it's better to let these remain orthogonal features. In general I think it is a net negative to usability when Feature A implicitly turns on Feature B. Implicit relationships like this make the Web platform more confusing. Security features are typically effective only when deployed in concert and when they default to their most restrictive state. As I understand, srcdoc is intended primarily as a security feature (because non-security use cases already have solutions). So, srcdoc should behave like a well-spec'd security feature and provide it's strongest level of protection by default, requiring the author to scale it back if needed. Otherwise we'll end up with common vulnerable cases because many people will expect secure default behavior, regardless of whether or not we spec it. At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote: On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: While talking with the implementor of @srcdoc in Webkit, it came up that, though @srcdoc is *designed* for use with @sandbox, the author still has to explicitly add @sandbox to the iframe or else they don't get the sandbox security model. Can we make this automatic? Specifically, when iframe srcdoc=foo/iframe is specified (without @sandbox), it drops into the sandbox security model as if iframe sandbox srcdoc=foo/iframe was used. If @sandbox is explicitly added, its value is instead used, so the author can set the sandbox security flags if desired. This would mean that there is no way for an author to use @srcdoc *without* sandboxing. This appears to be a minority use-case in the first place (as far as I can tell, it's pretty much just useful for testing purposes), but the author can always use a data: url in that case. I think it's better to let these remain orthogonal features. In general I think it is a net negative to usability when Feature A implicitly turns on Feature B. Implicit relationships like this make the Web platform more confusing. While I agree with you in general, in this particular case I cannot. @srcdoc wasn't designed as an orthogonal feature - it was explicitly built with @sandbox in mind, to allow authors to shove generic content into the sandbox without incurring a network request. It has only niche technical use outside the context of @sandbox. Should @seamless imply @sandbox too, then? Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 4:11 PM, Tab Atkins Jr. wrote: On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth w...@adambarth.com wrote: On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote: Should @seamless imply @sandbox too, then? I think there lots of use cases for seamless that don't require sandbox. For example, suppose a site wants to show a login form on many pages by only wants to implement the login logic once. It's entirely reasonable to wish to place the login form in a seamless iframe. If we required @sandbox for seamless, that would interfere with the login form working properly with password managers. Precisely; @seamless was *not* designed with the intention of always being used with @sandbox. It's just a nice feature to have for iframes in general. So there's no real connection between @seamless and @sandbox like there is between @srcdoc and @sandbox. @seamless was in fact designed to help @sandbox meet more use cases (in particular ones where embedding untrusted content in a fixed rect is not sufficient). But it can be used without @sandbox, and has some plausible uses along those lines, though they were not the initial use cases considered. LIkewise for @srcdoc. Indeed, many use cases are well-served by using all three in tandem. My point being, don't mix up orthogonal features in arbitrary ways. If @srcdoc implies @sandbox, but @seamless does not, someone reviewing for security has to remember exactly which set of similar-sounding attributes cause sandboxing, instead of following the simple rule just look for @sandbox. Things are clearer when security policy is explicit, and not implied by non-security behaviors. Regards, Maciej
Re: [whatwg] Built-in image sprite support in HTML5
On Aug 25, 2010, at 7:00 PM, Silvia Pfeiffer wrote: There are recommendations for what to do with video in the browser. I can encourage the group to also make recommendations for what it means for images in the browser. However, the use of Media Fragment URIs in applications in general really cannot be prescribed - what a video editor does with a media fragment URI is different to what a video playlist player does and again different to what it means in the browser and probably different again for pick your random application here. Not all applications display a timeline - not all applications allow interaction with the resource, some applications want to use the resource in context (i.e. with access to the rest of the resource), others don't. It is early times for Media Fragment URIs so some of these use cases will have to be experimented with before a good recommendation can be made. When different kinds of applications may need different behavior, one possible solution is for the spec to have different conformance classes. In this case, for the feature to be useful for Web content authors, it's pretty important for browsers to all do the same thing, even if other types of applications may behave differently. I will take the desire to have a clear specification for what Web browsers are to do with Media Fragment URIs back into the Media Fragment WG. I believe Web browsers are a special and the most important use case for such URIs, so it makes sense to specify that clearly. Yes, definitely. It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? It should crop to the selected region, i.e. create a sprite. This is a more generally useful behavior. Regards, Maciej
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Aug 14, 2010, at 10:14 PM, Robert O'Callahan wrote: On Sun, Aug 15, 2010 at 12:17 PM, Adam Barth w...@adambarth.com wrote: That's difficult to say given that it's supported in most browsers. We'd need to look for folks complaining to Mozilla. There's a tree of duplicate bug reports that lead to https://bugzilla.mozilla.org/show_bug.cgi?id=264412, but none since 2006. In 2006, you said you'd probably add it to HTML5: https://bugzilla.mozilla.org/show_bug.cgi?id=343357#c2. :) I doubt that IE or WebKit will remove support at this point, which leaves this as an inviting interoperability trap for developers who don't test in every browser. If it's not needed for compatibility, why wouldn't Webkit consider removing it? We'd probably weigh the following factors: - Is it likely WebKit-specific content relies on it? Probably yes. - Is it a genuinely useful feature? Yes, the ability to get plaintext content as rendered is a useful feature and annoying to implement from scratch. To give one very marginal data point, it's used by our regression text framework to output the plaintext version of a page, for tests where layout is irrelevant. A more hypothetical use would be a rich text editor that has a convert to plaintext feature. textContent is not as useful for these use cases, since it doesn't handle line breaks and unrendered whitespace properly. - Do other browsers implement it? Seems like all but Firefox do. These factors would tend to weigh against removing it. On Aug 14, 2010, at 11:16 PM, Robert O'Callahan wrote: Wouldn't you consider the interoperability benefits to the Web platform? We do consider this, but since the status quo is every browser but Firefox implements it, it's not clear that flipping WebKit-based browsers from one column to the other is a genuine interoperability improvement. Nor does it seem clear that changing all other browsers to match the odd man out is even the best overall strategy to getting there. Regards, Maciej
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Aug 15, 2010, at 10:27 PM, Mihai Parparita wrote: On Sun, Aug 15, 2010 at 8:41 PM, Robert O'Callahan rob...@ocallahan.org wrote: actually a useful and needed feature, we should hear it. Or if someone from Webkit or Opera wants to explain why they added it, that would be useful too. FWIW, WebKit has supported innerText since at least when it branched from KHTML (so most likely KHTML implemented it even before then): http://trac.webkit.org/browser/trunk/WebCore/khtml/dom/html_element.cpp?rev=4#L157 Indeed, we inherited the feature. Though it has also been improved over time to better match IE, and in general to give better fidelity. Much of the same code is shared by other parts of the engine that want the plain text version of some part of a Web page, for example, producing plain text for the clipboard or for assistive technologies via accessibility APIs. Regards, Maciej
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Aug 16, 2010, at 2:49 AM, Anne van Kesteren wrote: On Mon, 16 Aug 2010 11:23:55 +0200, Maciej Stachowiak m...@apple.com wrote: We do consider this, but since the status quo is every browser but Firefox implements it, it's not clear that flipping WebKit-based browsers from one column to the other is a genuine interoperability improvement. Nor does it seem clear that changing all other browsers to match the odd man out is even the best overall strategy to getting there. We would need to get a very solid definition for it though as it is not at all implemented in the same way. I agree that to achieve full interop it would require a proper spec. http://software.hixie.ch/utilities/js/live-dom-viewer/ !DOCTYPE html...span style=display:blocktest/spanscript w(encodeURI(document.body.innerText)) /script Opera does not use a newline for span set to display:block and includes (contrary to e.g. Chrome) the contents of the script element. If this can somehow share a lot of code with copy and paste -- as you indicate -- that does make it more interesting to keep, in my opinion. (What is up with Safari and the w() function on Live DOM Viewer by the way? It very rarely works for me. Do I need to run nightlies?) Worked for me in both Safari 5.0.1 and a recent nightly when I tried it. Regards, Maciej
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Aug 4, 2010, at 2:40 PM, Jonas Sicking wrote: On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell slightly...@google.com wrote: Sorry for the lagged response, On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt oli...@apple.com wrote: On Jul 30, 2010, at 2:46 PM, Alex Russell wrote: Wait...what? Shouldn't some sort of NodeList be mutable? And shouldn't JS support immutable Arrays? We need to fix both of these APIs, and we keep heaping back-pressure on JavaScript's Array without any reasonable resolution because we're not exploring how to make Array subtypes work as we want them to for all the use cases (like this) that we care to express. What would you expect a mutable NodeList to be? A good example would be the result of document.querySelectorAll(). Why couldn't querySelectorAll return a normal Array? I think in principle it could, but it might be too much compat risk to do now. Returning a fully mutable array would also remove the opportunities to cache and reuse the return value, since each result would really need to be distinct if they are mutable. Regards, Maciej
Re: [whatwg] HTML resource packages
On Aug 3, 2010, at 5:31 PM, Justin Lebar wrote: We at Mozilla are hoping to ship HTML resource packages in Firefox 4, and we wanted to get the WhatWG's feedback on the feature. For the impatient, the spec is here: http://people.mozilla.org/~jlebar/respkg/ and the bug (complete with builds you can try and some preliminary performance numbers) is here: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 Have you done any performance testing of this feature, and if so can you share any of that data? I'm particularly interested in: * Effect of using a resource package on page-load time, in the initial fully uncached case. * Effect of using a resource package on page-load time, in the case where the resources in the package have expired but not have changed. * Effect of using a resource package on page-load time, in the case where the resources in the package have expired and a subset of them have changed. (This could still be a win for packages.) * Effect of using a resource package on page-load time, in the case where everything in the package is cached. These are probably most interesting under high-latency network conditions (real or simulated). You address these points qualitatively in your comments but I'd love to see some numbers. That would make it easier to evaluate the performance tradeoffs. Separately, I am curious to hear how http headers are handled; it's a TODO in the spec, and what the TODO says seems poor for the Content-Type header in particular. It would make it hard to use package resources in any context that looks at the MIME type rather than always sniffing. Any thoughts on this? In general I am in favor of features that can improve page load times and which are Cheers, Maciej
Re: [whatwg] Please consider dropping the sandbox attribute from the iframe element
On Aug 1, 2010, at 6:59 PM, Tantek Çelik wrote: Summary: The new 'sandbox' feature on iframe should be considered for removal. It needs a security review, it will be a lot of work to implement properly, and may not actually solve the problem it is intending to solve. More details here: http://wiki.whatwg.org/wiki/Iframe_Sandbox I encourage fellow web authors and browser implementers to add their opinions/comments to that wiki page. As other have mentioned, iframe sandbox has been implemented in WebKit for some time. Additional points of information: 1) It's shipping in current versions of Safari and Chrome. 2) Security experts have reviewed it. @sandbox itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and @seamless. 3) Content has been built using it. 4) While it's unclear if iframe sandbox will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like gadgets and ads. While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable. The initial patch implementing it for WebKit can be seen here: http://trac.webkit.org/changeset/51577. This patch was 100k, but more than half of it is tests and the ChangeLog entry. Regards, Maciej
