5 ms·

This is silly and makes things way more complicated than they need to be. We have HTML tags, to which we can apply attributes directly via blah=blah syntax Or

This is silly and makes things way more complicated than they need to be. We have HTML tags, to which we can apply attributes directly via blah=blah syntax Or we can add attributes by making a style attribute, and using css syntax inside of it. Or we can have a space separated list of class names, and have attributes applied to an element externally by a CSS stylesheet. Or we can have an ID, and apply attributes using javascript. We can apply attributes with http headers, and the browser can negotiate the resource with http accepts and quality parameters. We have video, audio, and object tags that can all have child elements. We have query parameters and fragment selectors, and path parameters, and post parameters and accept parameters for negotiating and selecting content from a server. (Designed to include ampersands which have to be entity encoded when used in HTML!) We have all these sophisticated overlapping complicated mechanisms for attaching attributes to elements in a webpage. We have huge pieces of software for parsing through this poorly thought through mess. But no, not a single one of these is good enough for this problem. LET'S INVENT A NEW SYNTAX AND ADD TO THE HEAP OF IDIOCY.

hoppipolla 14y ago
From an implementation point of view, putting everything in a single attribute is way simpler; the design of <video> is quite problematic. The reason is that with a single attribute everything can be processed atomically. With a design based on multiple elements things can happen between elements being processed, creating many more edge cases. Although in general things that make authoring easier are preferred, designs that are easy to implement in a bug-free way are generally preferred over designs that are complex and likely to lead to interoperability issues. After all, having to fight implementation differences is a rather common complaint about the web platform. It also hasn't been clearly demonstrated that multiple elements are easier to work with. They are more familiar, but significantly more verbose. I don't know how that plays out in practice.
- ZenPsycho 14y ago
  I gave you a whole list of options but you only focus on these two. why?
  - hoppipolla 14y ago
    Because I was making a specific point about the implementation complexity of things that depend on attributes vs things that depend on many elements.
- ZenPsycho 14y ago
  And even if what you say about nesting is true- It's already a part of the standards for video, audio, and objects. It's not like we can change our minds about those. So we make the whole language inconsistent just because?
mcobrien 14y ago
Using CSS means you have to specify image locations in two places, with potentially different base URLs. Using Javascript means you have to load scripts before the img tag, which can hurt performance. Using http headers or a special URL format makes working with CDNs more difficult. This is actually a tricky problem to solve and it looks like the authors have considered some of the above problems. (I still hope they change it. Nested elements might be a way to go.)
- ZenPsycho 14y ago
  wait hold on how does having a query string in a url make CDN's more difficult?
  - cleverjake 14y ago
    You would need to turn on caching on your query strings in order for this idea to be useful with a cdn (ie, both http://example.org/image.png?size=big http://example.org/image.png?size=big and http://example.org/image.png?size=small http://example.org/image.png?size=small would need to be cached by the cdn). The issue is if you use some sort of user tracking, or rss feed, or anything that appends unique data to the end of the URL (so http://example.org/image.png?size=small http://example.org/image.png?size=small could become something like http://example.org/image.png?size=small&user=19hv839&time=1337089844 http://example.org/image.png?size=small&user=19hv839&#38...). At that point, every single person is getting the uncached version of the site, since their unique url was never cached before. Its not difficult to configure this sort of thing by any stretch of the imagination, but it does add another step.
    - ZenPsycho 14y ago
      why is your user tracking appending data onto the end of a CDN image? This hypothetical web site makes no sense.
      - cleverjake 14y ago
        The last time I had to deal with this it was a result of links to a site from an email being attached to the user it was sent to (eg example.com/?email=foo@bar.com). It was not a wonderful example, just a quick one. The moral being by caching query strings you risk needing to parse the ones being passed to ensure there in not unnecessary caching.
VMG 14y ago
most of your suggested alternatives are worse

hoppipolla 14y ago

From an implementation point of view, putting everything in a single attribute is way simpler; the design of <video> is quite problematic. The reason is that with a single attribute everything can be processed atomically. With a design based on multiple elements things can happen between elements being processed, creating many more edge cases. Although in general things that make authoring easier are preferred, designs that are easy to implement in a bug-free way are generally preferred over designs that are complex and likely to lead to interoperability issues. After all, having to fight implementation differences is a rather common complaint about the web platform. It also hasn't been clearly demonstrated that multiple elements are easier to work with. They are more familiar, but significantly more verbose. I don't know how that plays out in practice.

ZenPsycho 14y ago
I gave you a whole list of options but you only focus on these two. why?
- hoppipolla 14y ago
  Because I was making a specific point about the implementation complexity of things that depend on attributes vs things that depend on many elements.
ZenPsycho 14y ago
And even if what you say about nesting is true- It's already a part of the standards for video, audio, and objects. It's not like we can change our minds about those. So we make the whole language inconsistent just because?

mcobrien 14y ago

Using CSS means you have to specify image locations in two places, with potentially different base URLs. Using Javascript means you have to load scripts before the img tag, which can hurt performance. Using http headers or a special URL format makes working with CDNs more difficult. This is actually a tricky problem to solve and it looks like the authors have considered some of the above problems. (I still hope they change it. Nested elements might be a way to go.)

ZenPsycho 14y ago
wait hold on how does having a query string in a url make CDN's more difficult?
- cleverjake 14y ago
  You would need to turn on caching on your query strings in order for this idea to be useful with a cdn (ie, both http://example.org/image.png?size=big http://example.org/image.png?size=big and http://example.org/image.png?size=small http://example.org/image.png?size=small would need to be cached by the cdn). The issue is if you use some sort of user tracking, or rss feed, or anything that appends unique data to the end of the URL (so http://example.org/image.png?size=small http://example.org/image.png?size=small could become something like http://example.org/image.png?size=small&user=19hv839&time=1337089844 http://example.org/image.png?size=small&user=19hv839&#38...). At that point, every single person is getting the uncached version of the site, since their unique url was never cached before. Its not difficult to configure this sort of thing by any stretch of the imagination, but it does add another step.
  - ZenPsycho 14y ago
    why is your user tracking appending data onto the end of a CDN image? This hypothetical web site makes no sense.
    - cleverjake 14y ago
      The last time I had to deal with this it was a result of links to a site from an email being attached to the user it was sent to (eg example.com/?email=foo@bar.com). It was not a wonderful example, just a quick one. The moral being by caching query strings you risk needing to parse the ones being passed to ensure there in not unnecessary caching.

VMG 14y ago

most of your suggested alternatives are worse