Re: [whatwg] The src-N proposal
On 19/11/13 22:07, Simon Pieters wrote: The selection algorithm would only consider source elements that are previous siblings of the img if the parent is a picture element, and would be called in place of the current 'process the image candidates' in the spec (called from 'update the image data'). 'Update the image data' gets run when an img element is created, has its src or crossorigin (or srcset if we still want that on img) attributes changed/set/removed, is inserted or removed from its parent, when source is inserted to a picture as a previous sibling, or a source that is a previous sibling is removed from picture, or when a source that is a previous sibling and is in picture has its src or srcset (or whatever attributes we want to use on source) attributes changed/set/removed. 'Update the image data' aborts if the parser-created flag is set. When img is inserted to the document, if the parser-created flag is set, the flag is first unset and then 'update the image data' is run but without the await a stable state step. This seems like a nice proposal. There seems to be a minor problem that elements created through innerHTML will have the parser created flag set and so will not start loading until they are inserted into the document. So you probably want to call the flag the delayed load flag or somesuch, and only set it if the parser isn't in the fragment case.
Re: [whatwg] The src-N proposal
On 19.11.2013 23:22, Tab Atkins Jr. wrote: +1. I'm totally fine with this, if the people who disliked multiple attrs are okay with multiple elements. +1 -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] The src-N proposal
On Wed, 20 Nov 2013 12:30:18 +0100, James Graham ja...@hoppipolla.co.uk wrote: This seems like a nice proposal. There seems to be a minor problem that elements created through innerHTML will have the parser created flag set and so will not start loading until they are inserted into the document. So you probably want to call the flag the delayed load flag or somesuch, and only set it if the parser isn't in the fragment case. Yeah, indeed, thanks. A separate case I was thinking about is more than one imgs in a picture, do we want both to work or just the first? The proposal right now would do both. If we want only the first, that means the selection algorithm needs to check that there are no previous img siblings. When an img is inserted to a picture so it becomes the first img, we need to rerun the selection algorithm on the next img sibling (i.e. the img element that was previously the first). Similarly when an img element is removed, the (new) first img child needs to run the selection algorithm. Although it involves more checks, I think it seems saner to have only the first img use the sources. -- Simon Pieters Opera Software
Re: [whatwg] The src-N proposal
On 20/11/13 12:07, Simon Pieters wrote: On Wed, 20 Nov 2013 12:30:18 +0100, James Graham ja...@hoppipolla.co.uk wrote: This seems like a nice proposal. There seems to be a minor problem that elements created through innerHTML will have the parser created flag set and so will not start loading until they are inserted into the document. So you probably want to call the flag the delayed load flag or somesuch, and only set it if the parser isn't in the fragment case. Yeah, indeed, thanks. A separate case I was thinking about is more than one imgs in a picture, do we want both to work or just the first? The proposal right now would do both. If we want only the first, that means the selection algorithm needs to check that there are no previous img siblings. When an img is inserted to a picture so it becomes the first img, we need to rerun the selection algorithm on the next img sibling (i.e. the img element that was previously the first). Similarly when an img element is removed, the (new) first img child needs to run the selection algorithm. Although it involves more checks, I think it seems saner to have only the first img use the sources. I'm not sure that the extra checks buy you much apart from implementation complexity. What are you trying to protect against?
Re: [whatwg] The src-N proposal
On Wed, 20 Nov 2013 13:11:01 +0100, James Graham ja...@hoppipolla.co.uk wrote: I'm not sure that the extra checks buy you much apart from implementation complexity. Maybe you're right. What are you trying to protect against? Nothing in particular, it was more of a gut feeling that one behavior was weirder. -- Simon Pieters Opera Software
Re: [whatwg] The src-N proposal
On Tue, Nov 19, 2013 at 11:22 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Nov 19, 2013 at 2:07 PM, Simon Pieters sim...@opera.com wrote: So: picture source ... source ... img src=fallback alt=... /picture The selection algorithm would only consider source elements that are previous siblings of the img if the parent is a picture element, and would be called in place of the current 'process the image candidates' in the spec (called from 'update the image data'). 'Update the image data' gets run when an img element is created, has its src or crossorigin (or srcset if we still want that on img) attributes changed/set/removed, is inserted or removed from its parent, when source is inserted to a picture as a previous sibling, or a source that is a previous sibling is removed from picture, or when a source that is a previous sibling and is in picture has its src or srcset (or whatever attributes we want to use on source) attributes changed/set/removed. 'Update the image data' aborts if the parser-created flag is set. When img is inserted to the document, if the parser-created flag is set, the flag is first unset and then 'update the image data' is run but without the await a stable state step. +1. I'm totally fine with this, if the people who disliked multiple attrs are okay with multiple elements. We can still handle all the things that src-N did, without the need for such compact microsyntaxes, too: 1. Art direction is handled by source media. 2. Multiple densities is handled by a list of url/density pairs in source src. 3. Variable-size images can be handled with a picture sizes attribute, and a list of url/size pairs in source src. +1 as well. I think it's worth while to enable the `sizes` attribute and url/density pairs on img as well. It would enable authors that have just variable-width images with no art-direction to avoid adding a picture with a single source. Also, the Client-Hints specification can rely on `sizes` (on both picture and img) for the resource-width header value, even if only a URL (with no density) is specified.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
I wasn't aware of the { content: replaced url(attr(src-big)); }
syntax. This looks indeed better when you want to keep the sources in
the img tag.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
content: replaced url(attr(data-mobile-retina))
}
}
@media (min-width: 640px) {
.artdirection {
content: replaced url(attr(data-tablet))
}
(...)
}
img src=low.png class=artdirection data-mobile-retina=high.png
data-tablet=wide.png data-4ktv=toobigforyourbandwitdh.png
alt=smth/
One minor problem is that content: replaced, just like
background-image, prevents the user from right click / save as the
image.
But how do I tell content: to replace the src attribute ? I can't
find the syntax spec. Because the same CSS could also be applied to
the image in video poster attribute if I could tell content to
replace the poster attribute.
When CSS or MQ aren't available, you still get low.png. It's still an
image and not a div so the alt attribute can keep the accessibility
(granted, you could apply aria roles on a div).
Of course there is always the possibility of .artdirection being
overriden later in the CSS. Maybe shadow dom could shield the original
art direction.
laurent
--
http://laurentperez.fr
J2EE tips and best practices
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] The src-N proposal
On Wed, Nov 20, 2013 at 12:32 PM, Yoav Weiss y...@yoav.ws wrote: I think it's worth while to enable the `sizes` attribute and url/density pairs on img as well. It would enable authors that have just variable-width images with no art-direction to avoid adding a picture with a single source. +1 to this, I think it would cover all bases nicely and not require extra markup for simple images.
Re: [whatwg] The src-N proposal
On 20/11/13 14:19, Shane Hudson wrote: On Wed, Nov 20, 2013 at 12:32 PM, Yoav Weiss y...@yoav.ws wrote: I think it's worth while to enable the `sizes` attribute and url/density pairs on img as well. It would enable authors that have just variable-width images with no art-direction to avoid adding a picture with a single source. +1 to this, I think it would cover all bases nicely and not require extra markup for simple images. (note that +1-type messages without additional substantive information are generally discouraged on this list. Not meaning to single you out particularly; there have been a few in this thread recently).
[whatwg] picture redux
Simon Pieters wrote up Kornel's earlier approach to a saner, more palatable source selection algorithm for picture (rather than copying video/audio). This approach also has a new wrinkle: picture *requires* an img child, and it's the img that still actually displays the image. The picture element is just a wrapper for the img+source elements, and provides a context for the source selection algorithm. This makes testing substantially easier, as we can limit ourselves to testing the source selection algorithm, and probably makes implementation easier as well. This new approach seems to reasonably popular. The major people supporting src-N are for it, plus several new people; in particular, Timothy from Apple has voiced support for it, as have several people such as James Graham who disliked src-N for its use of multiple attributes. On Tue, Nov 19, 2013 at 2:07 PM, Simon Pieters sim...@opera.com wrote: On Tue, 19 Nov 2013 12:40:17 +0100, James Graham ja...@hoppipolla.co.uk wrote: On 19/11/13 01:55, Kornel Lesiński wrote: On Tue, 19 Nov 2013 01:12:12 -, Tab Atkins Jr. jackalm...@gmail.com wrote: AFAIK it makes it as easy to implement and as safe to use as src-N. Simon, who initially raised concerns about use of source in picture found that solution acceptable[2]. I'd love to hear feedback about simplified, atomic source from other vendors. The cost there is that picturesource is now treated substantially differently than videosource, despite sharing a name. The substantial difference is that it lacks JS API exposing network/buffering state, but IHMO that's not a big loss, as those concepts are not as needed for pictures. IMHO the important thing is that on the surface (syntactical level) they're the same - multiple source elements where the first one matches. So the remaining objections I am aware of to atomic-source are: * Something related to animations. I don't actually understand this, so it would be nice if someone who does would explain. Alternatively this might not actually be an issue. * Verbosity. This proposal is clearly verbose, but it is also the one that authors seem to prefer, largely because it uses the underlying markup syntax in a natural way. It seems that people will likely deal with the verbosity by copy and paste, templates or libraries to provide a convenient shorthand. If the latter occurs we can look at standardising it later. * More testing is needed. Specifically it seems that tests will be needed to use source elements (or picture elements?) where you can currently use img elements. This is a real concern of course, but seems lower on the priority of constituencies than authoring concerns, unless we think that poor interop will poison the feature. With an atomic proposal this seems much less likely, Hopefully implementations will be able to reuse the existing img code so that the actual amount of new *code* to test is less than you might think by looking at the extra API surface. Also see discussion in http://krijnhoetmer.nl/irc-logs/whatwg/20131119#l-537 In http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0045.html I discuss a problem that a new element would have, namely that it would require a new fallback mechanism and a lot of stuff would need to be duplicated from img. If we want to avoid that problem but still use source elements, that is possible by using img for rendering the image and source for providing the sources. There is precedent for this sort of thing in HTML, namely input list=x datalist id=xoption.../datalist. My first idea along these lines was to use img list= sourcelistsource ../sourcelist where, if the img element has a list attribute, the next element sibling is used for the sources. However, Anne pointed out a problem that it wouldn't work so well if you want to create the image in script and have it load without appending it to the document, since they wouldn't be siblings. There are ways to make it work but it would be non-obvious and it's better to come up with something that just works. So my next idea is to put the img element inside the sourcelist element, like so: sourcelist img list= source... /sourcelist The sourcelist element would be a normal inline element and only serve to bind together the img with the source elements. I've left the list attribute on img because currently the img src would start loading as soon as the element is created by the HTML parser, before the element is inserted to the document so there is no parent. If we want to get rid of the attribute, we can make the HTML parser set a parser-created flag on the img element and upon element creation, if the flag is set, do nothing, and when it is inserted to the document, if the flag is set, unset it and run 'update the image data' steps. (The spec says to await a stable state before downloading anything, I don't know if browsers want img to wait with downloading until the
Re: [whatwg] picture redux
It does look good to me, though I can't evaluate it from an implementation perspective. I'll defer to others on that. Requiring the img also also forces backwards comparability for clients that don't support picture. (As long as the author gives it a fallback src attribute.) One part isn't clear to me yet: what source attribute is used for DPR multipliers? Allowing both multipliers and intrinsic widths would be ideal and flexible. — Timothy Hatcher On Nov 20, 2013, at 9:25 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: picture *requires* an img child, and it's the img that still actually displays the image. The picture element is just a wrapper for the img+source elements, and provides a context for the source selection algorithm. This makes testing substantially easier, as we can limit ourselves to testing the source selection algorithm, and probably makes implementation easier as well.
Re: [whatwg] The src-N proposal
Am 20.11.2013 06:24 schrieb Bruno Racineux: On 11/19/13 12:12 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 19 Nov 2013, Markus Ernst wrote: I can't recall the reasons why Florian's proposal of combining picture and @srcset fell out of the discussion. To me it still looks like the most useable draft so far. I responsed to proposals along those lines last year: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.htm l Search for multi-element for the specific response to proposals that involve multiple elements. There are other concerns against any non-centralized approaches like picture. [...] Any author used to the flexibility of css shouldn't have the burden to deal with hard-coded unalterable stuff like that. It's as bad as an inline css-style to deal with. I do totally agree with you. AFAICS, all proposals with a significant amount of support (picture, srcset, src-N) share this problem. I don't have the impression that adding centralization has much support right now. Anyway, once there is a consent about the respImg syntax, it may be easier to propose a centralisation mechanism at the CSS side, e.g. some variable or constant useable in the MQ.
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 10:31 AM, Timothy Hatcher timo...@apple.com wrote: It does look good to me, though I can't evaluate it from an implementation perspective. I'll defer to others on that. Requiring the img also also forces backwards comparability for clients that don't support picture. (As long as the author gives it a fallback src attribute.) One part isn't clear to me yet: what source attribute is used for DPR multipliers? Allowing both multipliers and intrinsic widths would be ideal and flexible. source src will contain a list of either url/density or url/size pairs. ~TJ
Re: [whatwg] picture redux
On Nov 20, 2013, at 10:42 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Nov 20, 2013 at 10:31 AM, Timothy Hatcher timo...@apple.com wrote: It does look good to me, though I can't evaluate it from an implementation perspective. I'll defer to others on that. Requiring the img also also forces backwards comparability for clients that don't support picture. (As long as the author gives it a fallback src attribute.) One part isn't clear to me yet: what source attribute is used for DPR multipliers? Allowing both multipliers and intrinsic widths would be ideal and flexible. source src will contain a list of either url/density or url/size pairs. ~TJ Can it be srcset so img srcset is also usable for simple cases? (Yes respec srcset or anything not named src.) — Timothy Hatcher
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 10:57 AM, Timothy Hatcher timo...@apple.com wrote: On Nov 20, 2013, at 10:42 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Nov 20, 2013 at 10:31 AM, Timothy Hatcher timo...@apple.com wrote: It does look good to me, though I can't evaluate it from an implementation perspective. I'll defer to others on that. Requiring the img also also forces backwards comparability for clients that don't support picture. (As long as the author gives it a fallback src attribute.) One part isn't clear to me yet: what source attribute is used for DPR multipliers? Allowing both multipliers and intrinsic widths would be ideal and flexible. source src will contain a list of either url/density or url/size pairs. Can it be srcset so img srcset is also usable for simple cases? (Yes respec srcset or anything not named src.) I don't have strong opinions on the name. ~TJ
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 9:25 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Simon Pieters wrote up Kornel's earlier approach to a saner, more palatable source selection algorithm for picture (rather than copying video/audio). This approach also has a new wrinkle: picture *requires* an img child, and it's the img that still actually displays the image. The picture element is just a wrapper for the img+source elements, and provides a context for the source selection algorithm. This makes testing substantially easier, as we can limit ourselves to testing the source selection algorithm, and probably makes implementation easier as well. Adam Barth brings up a wrinkle on blink-dev, based on an older objection he had to picture. At that time, Blink was considering moving its preload scanner off-main-thread, and Adam wanted to make sure that the design of picture didn't preclude that from happening. Now, our preload scanner *is* on a separate thread, so we're definitely constrained in what we can do there. His basic concern is that MQs are too complex to be done off-main-thread, so it's hard/impossible to do MQs in the preload scanner. My response is that *some* MQs are perfectly fine to do off-thread, as they're basically just static properties of the display. John Mellor, who's done some preliminary work around this in Blink, supports this. We can just hand the relevant data to the preload scanner and do simple MQ parsing. We don't need to actually limit the MQs which are allowed in picture. The preloader is just an optimization in the first place; we *want* the image to be preloaded, but if it isn't, the image will still work, just slower. We can provide a note about which types of MQs are likely to be recognized by the preloader. Unrecognized MQs can just cause the preloader to ignore that source, and if that means an incorrect source is selected, that's just a wasted download, but back on the main thread, the source selection algorithm will pick the right picture a little bit later. Regardless of how we do this, though, *some* form of MQ or MQ-like functionality is part of *every* proposal that has been brought forward, as it's necessary for resolving several of the use-cases. ~TJ
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 9:25 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Simon Pieters wrote up Kornel's earlier approach to a saner, more palatable source selection algorithm for picture (rather than copying video/audio). This approach also has a new wrinkle: picture *requires* an img child, and it's the img that still actually displays the image. The picture element is just a wrapper for the img+source elements, and provides a context for the source selection algorithm. This makes testing substantially easier, as we can limit ourselves to testing the source selection algorithm, and probably makes implementation easier as well. On blink-dev, Adam Barth brought up an older objection he had to the original picture proposal. (This also applied to src-N, but Adam didn't realize that it applied.) At the time (back in April), we in Blink were considering moving our preloader to another thread, and by now we've actually done it. However, in general, MQ parsing and resolving is complex and relies on data structures on the main thread. Note, though, that some types of information that MQs can express, such as resolution, width, or height, are a requirement of *every* proposed solution. We obviously need to be able to use this information in the preloader in order to get *any* responsive images solution working. Luckily, these pieces of information are fairly static, and John Mellor confirms that they should be trivial to copy the info over to the preloader thread. Combine this with a simple parser for media features (simple to do alongside the other parsing), and you can do several of the most necessary MQs without a problem. This then brings up the question of what to do with unfriendly MQs that rely on more complex information that can't be reasoanbly shipped over to the preloader thread, like (pointer). I suggest that the preloader simply treat these as unknown (and thus false). In some cases this won't matter; the correct choice'll be taken even with the other ones ignored. In cases where it does matter, and the preloader ends up skipping an MQ for a source that it should have chosen if it had all the information, oh well, it'll kick off a wasted download. The main thread can verify this sometime later and select the correct source, so the right image gets selected, just a little late. This lets us avoid normatively specifying which MQs are compatible with the preloader, as it's just an optimization (though we should definitely *informatively* provide a list of common ones), and it avoids constraining the future design of either preloaders or MQs. ~TJ
Re: [whatwg] picture redux
Am 20.11.2013 22:27 schrieb Tab Atkins Jr.:
On Wed, Nov 20, 2013 at 9:25 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Simon Pieters wrote up Kornel's earlier approach to a saner, more
palatable source selection algorithm for picture (rather than
copying video/audio). This approach also has a new wrinkle:
picture *requires* an img child, and it's the img that still
actually displays the image. The picture element is just a wrapper
for the img+source elements, and provides a context for the source
selection algorithm. This makes testing substantially easier, as we
can limit ourselves to testing the source selection algorithm, and
probably makes implementation easier as well.
Adam Barth brings up a wrinkle on blink-dev, based on an older
objection he had to picture.
At that time, Blink was considering moving its preload scanner
off-main-thread, and Adam wanted to make sure that the design of
picture didn't preclude that from happening. Now, our preload
scanner *is* on a separate thread, so we're definitely constrained in
what we can do there.
His basic concern is that MQs are too complex to be done
off-main-thread, so it's hard/impossible to do MQs in the preload
scanner.
My response is that *some* MQs are perfectly fine to do off-thread, as
they're basically just static properties of the display. John Mellor,
who's done some preliminary work around this in Blink, supports this.
We can just hand the relevant data to the preload scanner and do
simple MQ parsing.
We don't need to actually limit the MQs which are allowed in
picture. The preloader is just an optimization in the first place;
we *want* the image to be preloaded, but if it isn't, the image will
still work, just slower. We can provide a note about which types of
MQs are likely to be recognized by the preloader. Unrecognized MQs
can just cause the preloader to ignore that source, and if that
means an incorrect source is selected, that's just a wasted download,
but back on the main thread, the source selection algorithm will pick
the right picture a little bit later.
Regardless of how we do this, though, *some* form of MQ or MQ-like
functionality is part of *every* proposal that has been brought
forward, as it's necessary for resolving several of the use-cases.
I am still very much concerned about centralizing MQs, and - without
knowledge about the preload scanner - I just wondered whether
centralization could be beneficial for the preload scanner, too. If we
had some kind of CSS constants available, this could look somehow like
(adapting the constant syntax suggested by fantasai years ago, just for
the sake of illustration):
head
style type=text/css
@define mediaqueries {
small: (max-width:479.99px);
medium: (min-width:480px) and (max-width:999.99px);
large: (min-width:1000px)
}
/style
/head
...
source media=small src=small.jpg 1x, small2.jpg 2x
...
Like this, MQs could be evaluated before the preload scanner is started,
I assume?
I am aware of the facts that the CSS aspects will have to be suggested
in the CSS WG list, and that no CSS constants are available so far. But
it would be nice if the respImg spec would be the way that it will
support centralized MQs, once they will be possible from the CSS side.
Thus my suggestion for the spec of the @media attribute in source: It
must contain a media query, or a value that represents the result of an
evaluated media query.
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 2:21 PM, Markus Ernst derer...@gmx.ch wrote:
I am still very much concerned about centralizing MQs, and - without
knowledge about the preload scanner - I just wondered whether centralization
could be beneficial for the preload scanner, too. If we had some kind of CSS
constants available, this could look somehow like (adapting the constant
syntax suggested by fantasai years ago, just for the sake of illustration):
head
style type=text/css
@define mediaqueries {
small: (max-width:479.99px);
medium: (min-width:480px) and (max-width:999.99px);
large: (min-width:1000px)
}
/style
/head
...
source media=small src=small.jpg 1x, small2.jpg 2x
...
Like this, MQs could be evaluated before the preload scanner is started, I
assume?
I am aware of the facts that the CSS aspects will have to be suggested in
the CSS WG list, and that no CSS constants are available so far. But it
would be nice if the respImg spec would be the way that it will support
centralized MQs, once they will be possible from the CSS side.
Thus my suggestion for the spec of the @media attribute in source: It
must contain a media query, or a value that represents the result of an
evaluated media query.
As I've argued before, and you acknowledge here, we should not tie
this into the responsive images proposal. It's separate and useful
for plenty of other things outside of responsive images.
Let's make sure that our responsive image solution is friendly towards
planned future MQ variables, but let's leave it off to the side while
we deal with the core problem. Hooking too many things together just
makes the entire assemblage more fragile and slower to spec and
implement.
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Sun, Nov 17, 2013 at 11:22 PM, Maciej Stachowiak m...@apple.com wrote: I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows: Thanks for explaining your position Maciej. 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 Can I focus on the viewport-urls syntax for a moment? Everything else (single attribute with ||s/multiple attributes/multiple elements/split between inline CSS HTML) is mainly just aesthetics. But the viewport-urls syntax provides a crucial bit of functionality, and I'd like to make sure people understand why it's so important. It resolves the fundamental tension between what authors want, chose image source based on layout size, and what browser developers want, don't break the preload scanner, in the very common variable-sized images (viewport-switching) case. Satisfying both conditions requires the author to tell the browser's preload scanner what the layout size of the image will be, in terms of the viewport size (and/or fixed sizes). That's all viewport-urls does: you express your layout image size as a CSS length (whose containing block is the viewport, as if you'd used position:fixed). For example: - 400px - 33% // equivalent to 33vw - calc(50vw - 80px) // flexible width with fixed padding It doesn't need to be exact (it's ok if most authors don't bother with calc), it just needs to approximate the layout image size such that the browser can determine the closest matching source. Finally, in cases where you have a nonlinear relationship between viewport width and image width (primarily in responsive designs where the number of columns changes due to a media query), you can provide a CSS length to either side of the discontinuities, where the discontinuity is expressed as a CSS min-width MQ, hence for a 1-3 column responsive grid you end up with something like the 100% (640px) 50% (960px) 33% examplehttp://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/you've probably seen. But again, while using this correctly will give you the optimal tradeoff between page load performance and image quality, it's generally ok if the long tail of websites don't bother dealing with the discontinuities, and just provide a rough estimate of image size, e.g. they approximate 100% (640px) 50% (960px) 33% as simply 600px. Finally, xanthir.com/b4Su0 explains why without viewport-urls, the markup complexity balloons (as an author still has to figure out the relationship between viewport width and layout image size, but then furthermore has to do a bunch of maths and sprinkle the breakpoints above as subtle variations in densities of the images they provide). Does this all make sense? Hopefully that helped explain why viewport-urls syntax (or something similar) is essential; but I'd definitely welcome suggestions to make it more human-understandable. The CSS lengths seem clear enough, but it's possible there's a better way of expressing the breakpoints... 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] picture redux
Something that just came to my mind: Unlike srcset and src-N, picture has the power to support MQs beyond viewport width: picture source media=screen src=... source media=print src=... img src=... /picture The UA will have to download both sources, or printing will be delayed. Is this a problem?
Re: [whatwg] picture redux
On Nov 20, 2013, at 2:37 PM, Markus Ernst derer...@gmx.ch wrote:
Something that just came to my mind: Unlike srcset and src-N, picture has
the power to support MQs beyond viewport width:
picture
source media=screen src=...
source media=print src=...
img src=...
/picture
The UA will have to download both sources, or printing will be delayed. Is
this a problem?
Building on this idea:
I have been thinking how the art direction use case is really limited to the
view port matches. (I understand that is because of preloader limitations.)
Ignoring the preloader for a minute, I can imagine other cases where art
direction can be useful based off of arbitrary CSS selector matches. Then
JavaScript could be in control of the source selection by setting classes — no
JS API required.
The idea would be to have named sources that can be chosen by a property in CSS
on the picture. If the same name is used by multiple sources, the first source
to match based on the other source attributes (media, sizes, etc.) is used.
Sources with no name would be used as the fallback/default.
This approach to script based art direction can be done today with multiple
img that are hidden and shown based on the same selectors. But using
picture and source this way should give more control over what images
actually load and don't load (ignoring preloader).
The preloader would likely skip any source with a name since we don't know if
the source is needed yet. That could cause double loading, so an attribute like
defer might be needed to prevent defaults from being preloaded.
Potential syntax:
picture
source name=foo src=foo.jpg
source name=bar srcset=bar.jpg 1x, b...@2x.jpg 2x media=screen
source name=bar src=bar-print.jpg media=print
source defer src=default.jpg
img
/picture
CSS syntax:
picture.hero {
source: none; /* Default */
}
body.art-directed-one picture.hero {
source: foo;
}
body.art-direction-two picture.hero {
source: baz;
}
or
picture.hero {
content: none; /* Default */
}
body.art-directed-one picture.hero {
content: replaced source(foo);
}
body.art-direction-two picture.hero {
content: replaced source(baz);
}
(Not sure if replaced would be required there or not.)
— Timothy Hatcher
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 2:37 PM, Markus Ernst derer...@gmx.ch wrote: Something that just came to my mind: Unlike srcset and src-N, picture has the power to support MQs beyond viewport width: I'm not sure where this belief that src-N doesn't support arbitrary MQs comes from. The syntax doesn't support media *types* (screen, print, etc), but media types are being deprecated *anyway*, and we're designing new media features that replace them. (Sorry to single you out - Adam Barth was under this impression as well. The spec just has this quite explicitly featured, so I'm confused about it.) picture source media=screen src=... source media=print src=... img src=... /picture The UA will have to download both sources, or printing will be delayed. Is this a problem? Printing can just be delayed. ~TJ
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 3:11 PM, Timothy Hatcher timo...@apple.com wrote:
On Nov 20, 2013, at 2:37 PM, Markus Ernst derer...@gmx.ch wrote:
Something that just came to my mind: Unlike srcset and src-N, picture has
the power to support MQs beyond viewport width:
picture
source media=screen src=...
source media=print src=...
img src=...
/picture
The UA will have to download both sources, or printing will be delayed. Is
this a problem?
Building on this idea:
I have been thinking how the art direction use case is really limited to the
view port matches. (I understand that is because of preloader limitations.)
Ignoring the preloader for a minute, I can imagine other cases where art
direction can be useful based off of arbitrary CSS selector matches. Then
JavaScript could be in control of the source selection by setting classes —
no JS API required.
The idea would be to have named sources that can be chosen by a property in
CSS on the picture. If the same name is used by multiple sources, the first
source to match based on the other source attributes (media, sizes, etc.) is
used. Sources with no name would be used as the fallback/default.
This approach to script based art direction can be done today with multiple
img that are hidden and shown based on the same selectors. But using
picture and source this way should give more control over what images
actually load and don't load (ignoring preloader).
The preloader would likely skip any source with a name since we don't know if
the source is needed yet. That could cause double loading, so an attribute
like defer might be needed to prevent defaults from being preloaded.
Potential syntax:
picture
source name=foo src=foo.jpg
source name=bar srcset=bar.jpg 1x, b...@2x.jpg 2x media=screen
source name=bar src=bar-print.jpg media=print
source defer src=default.jpg
img
/picture
CSS syntax:
picture.hero {
source: none; /* Default */
}
body.art-directed-one picture.hero {
source: foo;
}
body.art-direction-two picture.hero {
source: baz;
}
or
picture.hero {
content: none; /* Default */
}
body.art-directed-one picture.hero {
content: replaced source(foo);
}
body.art-direction-two picture.hero {
content: replaced source(baz);
}
(Not sure if replaced would be required there or not.)
This sounds interesting, but it looks like something we can add to the
proposal later. Do you mind holding off on this until we get a final
decision on the base proposal?
~TJ
Re: [whatwg] picture redux
On Nov 20, 2013, at 3:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 20, 2013 at 3:11 PM, Timothy Hatcher timo...@apple.com wrote:
On Nov 20, 2013, at 2:37 PM, Markus Ernst derer...@gmx.ch wrote:
Something that just came to my mind: Unlike srcset and src-N, picture has
the power to support MQs beyond viewport width:
picture
source media=screen src=...
source media=print src=...
img src=...
/picture
The UA will have to download both sources, or printing will be delayed. Is
this a problem?
Building on this idea:
I have been thinking how the art direction use case is really limited to the
view port matches. (I understand that is because of preloader limitations.)
Ignoring the preloader for a minute, I can imagine other cases where art
direction can be useful based off of arbitrary CSS selector matches. Then
JavaScript could be in control of the source selection by setting classes —
no JS API required.
The idea would be to have named sources that can be chosen by a property in
CSS on the picture. If the same name is used by multiple sources, the first
source to match based on the other source attributes (media, sizes, etc.) is
used. Sources with no name would be used as the fallback/default.
This approach to script based art direction can be done today with multiple
img that are hidden and shown based on the same selectors. But using
picture and source this way should give more control over what images
actually load and don't load (ignoring preloader).
The preloader would likely skip any source with a name since we don't know
if the source is needed yet. That could cause double loading, so an
attribute like defer might be needed to prevent defaults from being
preloaded.
Potential syntax:
picture
source name=foo src=foo.jpg
source name=bar srcset=bar.jpg 1x, b...@2x.jpg 2x media=screen
source name=bar src=bar-print.jpg media=print
source defer src=default.jpg
img
/picture
CSS syntax:
picture.hero {
source: none; /* Default */
}
body.art-directed-one picture.hero {
source: foo;
}
body.art-direction-two picture.hero {
source: baz;
}
or
picture.hero {
content: none; /* Default */
}
body.art-directed-one picture.hero {
content: replaced source(foo);
}
body.art-direction-two picture.hero {
content: replaced source(baz);
}
(Not sure if replaced would be required there or not.)
This sounds interesting, but it looks like something we can add to the
proposal later. Do you mind holding off on this until we get a final
decision on the base proposal?
~TJ
I agree. It can happen later.
— Timothy Hatcher
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 11:19 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: I'm not sure where this belief that src-N doesn't support arbitrary MQs comes from. The syntax doesn't support media *types* (screen, print, etc), but media types are being deprecated *anyway*, and we're designing new media features that replace them. Supporting media types (or whatever you're working on to replace them) is one of the use cases that is in the Use Cases and Requirements document [1]. I personally also have a particular interest when it comes to supporting print, it is something that not enough sites (including, currently, my own) do properly but a surprisingly high number of people do print off articles, especially technical documents. So supporting print and other types of media would definitely be an advantage. [1] http://usecases.responsiveimages.org/#h3_matching-media-features-and-media-types
Re: [whatwg] picture redux
On Wed, Nov 20, 2013 at 4:12 PM, Shane Hudson m...@shanehudson.net wrote: On Wed, Nov 20, 2013 at 11:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I'm not sure where this belief that src-N doesn't support arbitrary MQs comes from. The syntax doesn't support media *types* (screen, print, etc), but media types are being deprecated *anyway*, and we're designing new media features that replace them. Supporting media types (or whatever you're working on to replace them) is one of the use cases that is in the Use Cases and Requirements document [1]. I personally also have a particular interest when it comes to supporting print, it is something that not enough sites (including, currently, my own) do properly but a surprisingly high number of people do print off articles, especially technical documents. So supporting print and other types of media would definitely be an advantage. Yeah, I definitely understand the use-case. The whatever [I'm] working on to replace them would work for src-N, but they're not done yet. picture has no such limitation; since it's not trying to cram MQs into an already crowded microsyntax, it can go ahead and accept full MQs, including media type. ~TJ
Re: [whatwg] The src-N proposal
On Wed, 20 Nov 2013 05:24:21 -, Bruno Racineux br...@hexanet.net wrote: If your sources and breakpoints are hard-coded in your articles (stored DB), and you suddenly have to change your site's theme, or add a new image at the platform level or a new resolution? What if one breakpoint is no longer relevant? Or what if you change designs with a complete new responsive approach? How does an inline syntax help me with that case? You can be stuck. That forces you to regenerate all the img src(s) of your articles with your new layout and new inline breakpoints. I sympathize with the problem. Unfortunately we have a hard requirement of supporting the preload scanner, which means we absolutely cannot wait for any external file. And since we can't wait for any external file, we can't wait for stylesheets or any reusable centralized definition of breakpoints. When HTTP/2 Push becomes a standard feature preload scanner won't be so important any more and we'll be able to revisit this. A centralized css-subset approach do not have such difficult problems. Verbose aside, to me this all screams: RespIMGs has to be a CSS related feature with centralization of custom MQs and srcset(s) at the head. With preload scanner limitation definitions in head is the best we could possibly do. I have proposed Media Query Variables intended to be used in style in head for responsive images. I've also wanted MQ variables to be usable in external stylesheets to reduce repetition in regular @media CSS, but even mere possibility of authors misusing external CSS definitions for responsive images (which would achieve centralization you want, but also get in the way of preload scanner) made browser vendors feel uneasy about this proposal. I hope to convince them otherwise, but until then your best bet is to use server-side templating language (or project-wide find and replace) to define your breakpoints once. -- regards, Kornel
Re: [whatwg] The src-N proposal
On Tue, 19 Nov 2013 22:07:33 -, Simon Pieters sim...@opera.com wrote: In http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0045.html I discuss a problem that a new element would have, namely that it would require a new fallback mechanism and a lot of stuff would need to be duplicated from img. Do we need usemap? We can probably drop it. We don't need to replicate lots of legacy features and quirks of img. I think the upside is that we can ship picture with almost no features, and re-add them only as necessary. For the fallback: canvas is an existing example of a picture with a fallback DOM, so browser vendors already have to implement/implemented fallback for picture-like element. I would go further and simplify it by forbidding all interactive (focusable) elements in picture fallback DOM. Canvas already forbids interactive elements with some exceptions, but for picture we don't even need these exceptions. This authoring rule can be validated easily, and allows UAs to avoid real difficulty of handling focus in fallback. To make picture easy to plug into existing ATs I suggest specifying that UAs MAY interpret fallback content as text extracted using innerText algorithm (preserves space between elements) with additional rule that @alt from any img in the fallback is extracted as well (so pictureimg alt=old alt/picture as well as picturepfancy alt/p/picture will have good accessibility in all UAs). This should be zero extra work for implementors, since that's what they already do for copying selection to plain text clipboard. With plain text extracted from the fallback it will be possible to reuse accessibility interfaces designed for img alt. When picture implementations mature we may eventually be able to let authors rely on more structured fallback. In any case we're better off than with strictly-plaintext-forever img alt, and the first version of picture can be guaranteed to be be easily implementable in terms of img. At this point we could change the name of the wrapping element to picture and basically have the same syntax as current picture except there would be a required img child element. The x-picture polyfill implements picture using img (http://uniqname.github.io/x-picture/), so that's definitely a way to do simple implementation. An img element will be de-facto required for a while as a fallback, but could it be optional eventually? I think that even if browsers implement picture using img, the img element itself should be hidden in shadow DOM. If we don't explicitly define picture as wrapper for img then yes, we'll need separate test cases for picture, but: - hopefully plenty of cases can be adapted with little more than find'n'replace img src= with picturesource src= - We don't need to bring all the legacy baggage of img, so a bunch of tests for Netscape'isms can be deleted. - Image element has weird stuff like .complete property that can change synchronously. Kill it! With clean slate we can define only minimal, quirk-free API that is much easier to deal with. - Test cases is something that can be shared between browser vendors, and the community can help adapt img test cases to picture, so we can spread the effort. -- regards, Kornel
Re: [whatwg] The src-N proposal
On Tue, 19 Nov 2013 20:12:23 -, Ian Hickson i...@hixie.ch wrote: I responsed to proposals along those lines last year: This may be a good time to revisit and re-evaluate this. When picture and srcset were proposed initially there was still a lot of confusion what reponsive image actually means and we spoke past each other a lot. RICG has collected, evaluated and categorized use cases (http://www.w3.org/TR/respimg-usecases/), so now we understand problems better and have terms like DPR switching and art direction to describe features we need. We've discussed many alternatives (multiple times, *sigh*) and picture is being refined. http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html Search for multi-element for the specific response to proposals that involve multiple elements. Here's that response: - it's closer to the solution to the similar problem that is being resolved for CSS, namely image-set(). image-set() solves the DPR switching use case quite well, but by itself it doesn't address art direction or other aspects. At the recent RICG meetup in Paris nobody could give a correct, straightforward explanation what combination of srcset w/h descriptors actually does, and meaning of the syntax was commonly misunderstood. The consensus was that it's a confusing syntax, w/h descriptors aren't going to be implemented, and that part of srcset should be dropped. So srcset is a good solution to one of the problems, but is not sufficient to end the discussion. The latest picture proposal adopts srcset, and srcset concept has been extended in src-N proposal to support remaining cases. - it doesn't involve multiple elements. Generally, processing models for multi-element structures in the DOM are a disproportionate source of trouble in a wide variety of areas: - they introduce the need for much more elaborate error handling, since they have multiple failure modes (what happens if one or another element is found in another, or if the outer element has an unexpected inner element?) It's enough to specify that picture should check its source children and implementation is quite simple: https://github.com/ResponsiveImagesCG/picture-element/issues/62#issuecomment-24479164 - the processing model has to deal with changes more complicated than just change (what if an element is added or removed, or moved?) The simplified source selection algorithm I've proposed solves this: evaluation of sources is scheduled to run on the next tick after mutation, and the algorithm is stateless, so it doesn't have to track mutations and JavaScript can't disrupt it. - it introduces all kinds of complicated questions once you introduce shadow trees (what if you bind something with a special child? what if the shadow tree contains such a child?) I'm not sure what kind of binding you mean. Can you elaborate? Fallback DOM in picture is similar to one we have in canvas, and I think it could be simplified even further by forbidding any interactive (focusable) content (that's not a loss compared to img alt=). - it introduces complexities in the algorithms to deal with unexpected text nodes, comment nodes, PIs, etc. if (children[i].nodeType != 3) continue; - it introduces some complexity in the parser, because you have to handle the case where you're only half-way through parsing the parent element when you return to the event loop, with more children elements to process (when does the processing model start? what do you expose in the DOM API half-way through? etc). Simplified source selection algorithm solves this. Following Simon Peters' suggestion it picks the first source that matches (and match is evaluated immediately without going to the network), so it won't trigger invalid download when presented with incomplete DOM during page load (packet boundary), and the preloader doesn't even have to wait for /picture end tag. - it resolves the intrinsic sizing for high-res images issue discussed earlier in this e-mail. This has been a problem with the earliest draft of picture, but now all proposals solve this as well. - it's a lot less verbose. For just 2x modifier srcset is nice and concise, but it quickly gets messy when you add more features. Some of the single-attribute proposals were pretty close to looking like Perl. Verbosity of picture is a cost of following design patterns prevalent in HTML, but it makes the syntax really easy to understand. We have select and not input optionset=, meta and not head meta-1= meta-2= etc. Ability to use named attributes on source makes it extensible in a straightforward manner. OTOH microsyntax with multiple delimiters is more prone to authoring errors and it's impossible to extend without complicating it even further (e.g. if we ever need more attributes for, say, 3d glasses, we can just add source 3dglasses= rather
Re: [whatwg] picture redux
On Wed, 20 Nov 2013 17:25:07 -, Tab Atkins Jr. jackalm...@gmail.com wrote: Simon Pieters wrote up Kornel's earlier approach to a saner, more palatable source selection algorithm for picture (rather than copying video/audio). This approach also has a new wrinkle: picture *requires* an img child, and it's the img that still actually displays the image. The picture element is just a wrapper for the img+source elements, and provides a context for the source selection algorithm. This makes testing substantially easier, as we can limit ourselves to testing the source selection algorithm, and probably makes implementation easier as well. Can we hide the controlling img in shadow DOM? And make HTMLPictureElement the interface that proxies relevant properties/events to the internal img? Reuse of img is a great idea for simpler implementation and testing, but maybe we don't even need to expose that fact to the authors. -- regards, Kornel
Re: [whatwg] picture redux
On Nov 20, 2013, at 7:06 PM, Kornel Lesiński kor...@geekhood.net wrote: On Wed, 20 Nov 2013 17:25:07 -, Tab Atkins Jr. jackalm...@gmail.com wrote: Simon Pieters wrote up Kornel's earlier approach to a saner, more palatable source selection algorithm for picture (rather than copying video/audio). This approach also has a new wrinkle: picture *requires* an img child, and it's the img that still actually displays the image. The picture element is just a wrapper for the img+source elements, and provides a context for the source selection algorithm. This makes testing substantially easier, as we can limit ourselves to testing the source selection algorithm, and probably makes implementation easier as well. Can we hide the controlling img in shadow DOM? And make HTMLPictureElement the interface that proxies relevant properties/events to the internal img? Reuse of img is a great idea for simpler implementation and testing, but maybe we don't even need to expose that fact to the authors. -- regards, Kornel Authors are likely going to need an explicit img for backwards compatibility anyway. Having an implicit img in the shadow DOM that is created if one isn't explicitly provided is interesting. — Timothy Hatcher
Re: [whatwg] The src-N proposal
On 11/20/13 6:09 PM, Kornel Lesiński kor...@geekhood.net wrote:
With preload scanner limitation definitions in head is the best we
could
possibly do. I have proposed Media Query Variables intended to be used in
style in head for responsive images.
I've also wanted MQ variables to be usable in external stylesheets to
reduce repetition in regular @media CSS, but even mere possibility of
authors misusing external CSS definitions for responsive images (which
would achieve centralization you want, but also get in the way of preload
scanner) made browser vendors feel uneasy about this proposal.
But having custom MQs in the head (on the main thread if I understand
well), actually helps the preloader, and as such, creates a 2 fold
situation, where external misuse fears is also hurdle to the preloader.
Perhaps separating MQ variables and/or 'CSS constants' in a separate
css type is a way to go then... just a syntax for example sake:
style text/x-cssvar
media { mobile : (max-width: 400px) ; }
/style
Since we'll use them for:
link rel=stylesheet href=/css/custom.css media=('mobile')
The text/cssvar type would logically belong to the head, above all other
css.
It helps mitigate those fears, and separate css custom variable
definitions from presentational css. i.e. You can't mix them up.
Re: [whatwg] Form-associated elements and the parser
There is a related quirk with respect to the isindex element. A start tag whose tag name is isindex http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#isindex Right now, form element pointer is not null in the following example, so we end up losing isindex element entirely. !DOCTYPE html htmlbodyformtemplateaisindex/isindexb/template Granted, isindex is a legacy element but it seems better to keep things consistent. - R. Niwa On Aug 13, 2013, at 7:08 AM, Adam Klein ad...@chromium.org wrote: On Tue, Aug 6, 2013 at 4:47 PM, Adam Klein ad...@chromium.org wrote: On Tue, Aug 6, 2013 at 4:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 6, 2013 at 4:27 PM, Adam Klein ad...@chromium.org wrote: On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking jo...@sicking.cc wrote: As I recall it (it was ages since I dealt with this), the tricky case that you need to handle is this one: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2432 In this case, web compatibility requires that the input is associated with the form. Specifically hidden input elements would often end up moved, but still had to show up in form.elements as well as get submitted along with the form. That case definitely makes sense to me, and I think it's fine to keep that behavior for compat. The only one I'm asking to change is the case when the input and form end up in different trees. Sure, as long as you come up with a formalized algorithm for when there is an association and when there isn't. Keep in mind that by the time that the input-element is inserted, the form-element might have been moved elsewhere. We likely don't need the association in that case, but detecting that that has happened sounds tricky. My concrete proposal would be something like this: In step 4 of http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token, add a requirement that intended parent and the form element pointer be part of the same home subtree (defined at http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree). For what it's worth, we're giving this a try in Blink (https://src.chromium.org/viewvc/blink?revision=155949view=revision), as it's by far the safest fix for the related crashes. I'll update this thread if we run into any compat issues in the wild (or if we don't!). - Adam The way that Gecko currently works IIRC is that it creates the association any time it has seen a form without seeing a /form. And it breaks the association anytime an input-element's parent chain changes and the associated form-element is no longer in the parent chain. This is basically the same thing Blink WebKit do, with the caveat that we also avoid associating forms with elements inside templates (this is now reflected in step 4 of the algorithm, see above). On a related note, when are you guys going to add a cycle collector or other not-plain-refcounting memory manager :-) Yes, that would be nice :) - Adam / Jonas On Tue, Aug 6, 2013 at 2:01 PM, Adam Klein ad...@chromium.org wrote: Hixie opened my eyes last week to parser-association behavior of the sort found at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428. In that case, an input in a detached tree is associated with a form in the main document. This causes badness in WebKit and Blink because the association between the form and the input (e.g., as exposed in the HTMLFormElement.elements collection) is only weakly held to avoid reference loops (and thus memory leaks). And that weakness occasionally results in crashes when one of these objects is collected before the other. While all modern HTML parser implementations I tested seemed to agree on their treatment of the above example (they all return 1 as elements.length), this feature doesn't strike me as terribly useful. And for what it's worth, it doesn't seem to be present in legacy IE. I'm interested what others would think about changing the parser to only associate a form with an input if both are in the same home subtree (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree). Or is there some deep web-compat reason for this parsing oddity? - Adam
