On Sat, Oct 19, 2013 at 7:00 PM, Maciej Stachowiak <[email protected]> wrote: > My initial impression is that it seems a bit overengineered.
Can you elaborate on these concerns? I tried to find the simplest set of features that solves the use-cases I was presented with in a good way: * lists of urls and resolutions, like basic srcset * use of familiar MQs rather than the new and, from developer feedback, rather confusing 100w terminology. * a variant of the above for handling cases where the image's sizes is variable, rather than known at authoring time, without needing to repeat yourself a ton. The FF and Blink implementors, several RICG folk, and a number of web authors have told me that they like src-n quite a bit. That's not conclusive, of course (we can definitely find people who dislike it, too), but it's not something I'm trying to push without any support. ^_^ On Sun, Oct 20, 2013 at 3:31 AM, PERIER Romain <[email protected]> wrote: > srcset is not complicated enough for a web developer? why do you want to > add complexity for the developer ? The srcset specification already convers > DRP switching and viewport (not implemented yet, but it is planned, it is in > my todo list) The src-n proposal is nearly a superset of srcset. For the simple, and expected to be most common, case of just delivering an image at various densities, the syntax is *identical* to srcset. The two other tweaks are just a modification to the viewport-switching from a brand syntax to a more familiar MQ-based syntax, and a shortcut syntax to make it possible to specify a variable-sized image without requiring the author to repeat their urls or do non-obvious math to discover where the best breakpoints are. That last one, in particular, is pretty important I think. Handling a variably-sized image in full srcset syntax is *possible*, but doing it well is quite a lot of work, and I don't think most authors will do so. Instead, they'll do the minimum amount of typing to get stuff to work on the devices they have, and I don't blame them for that. However, this means that monitor sizes outside the range they thought about aren't served well, nor are future higher densities: why would anyone purposely add a 3x or 4x image when such devices don't exist yet; why would anyone spend the effort to provide <1x density images for low-bandwidth connections when *their* bandwidth is just fine? If you last read the spec more than a week ago, I rewrote the section concerning this last grammar branch to make it much easier to understand what it's for, and added more example. Please give it a whirl and see if you understand my point a little better. > why don't you propose improvements to the original > specification/implementation instead of reinventing the wheel ? > Syntaxically-speaking, it's not smart. srcset cannot be reasonably extended into something that solves the problems as well as I think that src-n does. I apologize for coming up with this idea relatively late in the process, but there's not much I can do about that now. That said, the processing algorithm already handles src as a fallback value, and there's an issue logged there talking about how srcset can be used as a fallback as well. While it would be ideal if we dropped our initial srcset implementations in favor of src-n, it's not killer if we end up keeping it and src-n both. On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <[email protected]> wrote: > Ignoring other aspects of this, the idea of making attribute name an > enumeration is somewhat distasteful. It will require ugly special parsing. > The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. As to the design concern, the platform certainly does already have lists, but putting this stuff into a single attribute would make it a list of lists, which is hard to read, write, and maintain. I felt that the pain of having lists of lists was worse for authors than the cost of understanding multiple attributes. I think it's similar to data-* - it *could* have been designed as a single "data" attribute, with either a microsyntax or maybe just JSON to allow you to specify multiple key-value pairs, but it was easier to read and write as separate attributes. The other approach to this is to use multiple elements, like <picture>/<source>. Several implementors have expressed concern with this approach from an implementation-difficulty perspective; there have been suggestions about how <source> processing could be tweaked to make it easier, but then we have the fairly bad situation of <source> acting differently in <video>/<audio> and <picture>. This approach also means you have to introduce new elements, rather than using the existing ones; this has both upsides and downsides, and I think ends up being about a wash. The numbering, too, serves an interesting purpose. Because the algorithm processes the src-n attrs in numerical order, you can write them in whatever order you wish. Mat Marquis, for example, finds it most convenient to use min-width MQs and arrange them in ascending order, as it's easier to read, but that's the opposite of the order they need to be evaluated in, so he can correct this by just writing the src-n attrs in descending order. He's given several examples of this when discussing this proposal. On Sun, Oct 20, 2013 at 2:08 PM, Benjamin Poulain <[email protected]> wrote: > On 10/20/13, 9:07 AM, Antti Koivisto wrote: >> Ignoring other aspects of this, the idea of making attribute name an >> enumeration is somewhat distasteful. It will require ugly special >> parsing. The platform has plenty of attribute values that are lists already. > > I was thinking the same thing last night. In addition to weirdness on > the engine side, it looks like a nightmare for authoring/tooling. > > Is there a precedent for this strange notation? Yes, data-* is somewhat of a precedent. This is, however, the first set of attributes that vary numerically, rather than by an arbitrary user-provided string. On Sun, Oct 20, 2013 at 3:29 PM, Antti Koivisto <[email protected]> wrote: > Also CSS selectors only support matching exact attribute names. There is no > way to write universal "elements with some srcN attribute" query for > example. This might not be important for practical uses here but it does > demonstrate that the approach is a poor fit to the platform. If this becomes important, we should extend CSS to do this. We have lots of attribute-matching functions for *values*, doing the same for *names* is likely possible. I think this *is* a generic problem, as I've heard similar complaints about the ability to style certain XML languages before. On Mon, Oct 21, 2013 at 3:15 AM, Michael[tm] Smith <[email protected]> wrote: > To give a specific example: I work on the code for the W3C validator and I can > tell you that implementing validator support for the srcN proposal would > require > adding a not-insignificant amount of new special-casing code that nothing else > has ever required, along with some greater-than-normal (though still > relatively > small) runtime cost. And the way I'd have to implement it seems hacky and > ugly and I'd really rather not do it unless there's no other alternative we > can get agreement on for solving the responsive-images problem. As I've argued before, I think "making validators easy to write" is a concern that's very, very low on the priority of constituencies. Only a few people ever write validators in the entire web, so it's okay to saddle them with extra engineering effort if it helps the other constituencies. Further, the problem you've described with validating these has nothing to do with src-n itself, but rather is a consequence of the particular technology the W3C's validator currently uses. Many possible validator architectures would have no problem at all with handling attributes like this. ~TJ _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
