Consider responsive element

UPDATE: Read this post if you want to know why we don’t need different content. Matt explains this in comments.

I recently saw this post and was happy to see what this man had done: http://css-tricks.com/lark-queries/. He changes content when viewing on different devices / media.

I think we need different resolutions and different content on different devices. Not every text is proper for a smartphone. This has also been addressed in several blog posts out there.

So why not covering this problem with our new syntax?

As Matt already proposed he’d like to have a universal indicator to reference the responsive-assets. Now we have the <picture>-element but why don’t we just use e.g. <responsive> as name so we can have any content in there?

<responsive> should then be a inline-element as we could have this inside a h1-h(n),p,span or other elements, I think. Or we need to identify the content by providing a type-attribute?
I know this is a request that isn’t simple and easy to figure out how to do it but I think it can be important to think about it because we’re now building the future of responsive assets for the next years! And I want a good solution :)

What do you think about this?

11 Responses to Consider responsive element

  1. Denys Mishunov says:

    That’s a very good point, Anselm. I have wrote a post on this exact topic with a little bit different conclusion — we don’t need a separate element. We might be just fine with a new attribute and that would solve most of the problems in my opinion.

    The problem is that this group’s task is not anything-responsive but exactly responsive images. And I see (I might be totally wrong though in this assumption) the group leaning towards a solution for this narrow issue rather than a more generic one.

    • Anselm Hannemann says:

      But how would you handle multiple sources on images then if we don’t have a new element?
      I think your div-markup isn’t good as semantically seen the three different contents doesn’t stick together. But they should. Because semantically they all represent the same meaning with different content.

      I also don’t like the idea of introducing the query attribute as we already have the media attribute. Why did you choose this?

  2. Matt Wilcox says:

    This is dangerous territory and I would not welcome it.

    Responsive sites are all about showing the same content but in device/user appropriate ways. The moment you start thinking you need to deliver different content because of the device is the moment you should be thinking about building a separate site in the old m.mysite.com way.

    It is this treatment of content which differentiates responsive from mobile solutions. Remember the rule that any public URL (i.e., one that doesn’t require a log-in) should offer the same content regardless of anything else – it’s a rule as old as the hills (in internet terms).

    • Matt Wilcox says:

      You can think of it in terms of accessibility if it makes more sense to you:

      Doing as you suggest would lead to situations where it becomes impossible for a user to get certain information solely because of the device they are using to access a URL. This is clearly a bad thing, and something from which the user can not recover.

      • Anselm Hannemann says:

        No, no, no. This is not what I intended. You just represent the same content in different ways. It can make sense to explain a video for eInk-reader-users while display-users get the video, right? This is what I intended. Improved accessibility, not decreased.

        • Matt Wilcox says:

          Explaining a video for e-ink readers is already built in to the spec, such devices don’t support video and should use a fallback provided inside the video tag. See the example here: http://www.w3schools.com/html5/html5_video.asp

          We should never be in a position where we supply different semantics on a URL, which is what the proposition allows. There are already mechanisms to deal with non-supporting devices.

          • Anselm Hannemann says:

            Okay, thanks for clarification, now it makes sense to me. Just didn’t knew about the video-fallback specified in spec.

    • Anselm Hannemann says:

      Matt, you are not wrong here. I just wanted to be sure that this is something we don’t want to address and not just forgotten it.

      I would like to hear some additional thoughts. :)

    • Jacob Mather says:

      I agree 100% on this. I’ve heard of people doing the whole “responsive content” thing and I get very Spaced Invaders on it (Just for the record, I thought this was a baaaad idea.)

  3. Ryan DeBeasi says:

    The demo above is cool, but I do think it goes against the purpose of responsive design. The idea is to make the same content available to a wide variety of devices in a way that makes sense on those devices. To do this, we take into account input methods, screen size/resolution, and bandwidth.

    For videos and images, it makes sense to present smaller versions on devices with low resolutions and limited bandwidth. We’re presenting the same content, but at a different size. The great thing about text is that it can be resized and adjusted using CSS; we don’t need to worry about bandwidth constraints.

    In general, presenting completely different content based on screen size violates users’ expectations and makes potentially incorrect assumptions how they’ll use the content. For those reasons, I think a tag would be overly broad and would actually do more harm than good.

  4. Pingback: Move on! | Responsive Images Community Group

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.