On Oct 22, 2013, at 1:50 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
> On Sat, Oct 19, 2013 at 7:00 PM, Maciej Stachowiak <m...@apple.com> wrote: >> My initial impression is that it seems a bit overengineered. > > Can you elaborate on these concerns? - The syntax is effectively a list of lists, the outer level being implicit in the numbers in the attribute names, and the inner being an explicit comma-separated list. That seems complicated. - Media queries are much more general than is actually needed for the use cases as outlined in the spec (even if reduced to only allowing a single clause). Granted, the useful subset of media queries is easier to read than w/h. - Even if you want to use only the inner level of list, you still need to acknowledge the implicit outer level (in which case having "src-1" or whatever in your markup seems weird). To be fair, this could be addressed by still supporting "srcset" and giving it a defined place in the resolution order, as proposed by the spec itself in "ISSUE 5". - The proposal defines a rather complicated structured microsyntax. That's from skimming the spec. My opinion could change on closer reading. Regards, Maciej > 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 <romain.per...@gmail.com> > 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 <koivi...@iki.fi> 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 <benja...@webkit.org> 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 <koivi...@iki.fi> 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 <m...@w3.org> 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev