Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Rewrote img-to-p fallback in the examples. #23

Merged
merged 2 commits into from Mar 20, 2013

Conversation

Projects
None yet
8 participants

notabene commented Mar 8, 2013

Usually I can either see the image or its @alt. The examples assumed that if line 1 doesn't apply, then line 2; if line 2 doesn't apply, then line 3, etc., (which is the proper way for this kind of stacked markup, granted). Thus the examples said somehow: if you don't display images using the img tab, then fall back to next line and display the paragraph. This is not the proper way things work, I think. Hoping I'm not too much intruding here, but I felt like helping on this issue. Please feel free to get in touch if I'm missing the point entirely.

Stephane Deschamps Rewrote fallback mechanism in examples
Usually I can either see the image or its @alt. The examples assumed that if line 1 doesn't apply, then line 2; if line 2 doesn't apply, then line 3, etc. Thus the examples said somehow: if you don't display images using the img tab, then fall back to next line and display the paragraph. This is not the proper way things work, I think. Hoping I'm not too much intruding here, but I felt like helping on this issue. Please feel free to get in touch if I'm missing the point entirely.
def6a2a
Member

anselmh commented Mar 8, 2013

Just a short note here: I do not think your change is the intended behavior. picture-element tries to improve the accessibility and therefore provide customizable alternative text (shown as a p-element in our examples). For the fallback you should provide an alt-text in the img tag but also can and should provide the alternate text for the non-fallback mode.

Surely @marcoscaceres knows the spec better about this point but I think we are still have some discussion on that specific point…

Owner

marcoscaceres commented Mar 9, 2013

Hi @notabene, thanks for the pull request. I'll review it in the next few days. In the mean time, it would be great if you could address @anselmh comments.

notabene commented Mar 9, 2013

Thanks both of you. Sorry for being a bit too quick on the pull request comment and not formatting, it was late and I'm quite new to github and markdown.

@anselmh my problem is this: the traditional browser behaviour that is expected is that if a tag isn't understood, the browser goes through it, ignores it and reads the following tags. This is how we've been able to add new tags and not break the web in older browsers: this is how it's always worked for html5 structural tags (article, aside, etc.) or for embed/applet/object constructs.

Here a browser which doesn't support the proposed construct will be parsing like this:

  1. picture tag? don't know, ignore
  2. source tag? don't know, ignore (repeat for each source tag met)
  3. img tag? OK this one I know: parse and show to the user.
    * can I display the image? OK, doing that.
    * if I can't display the image (or someone is using a screen reader), use the alt attribute instead
  4. p tag? OK this one I know: again, parse and show the user.

So this idea of using the first know tag in the list of successive fallbacks provided is valid indeed, but it does not work when two tags in a row are recognized by an older browser that does not understand the other tags.

At least this is my understanding of the parsing algorithm.

Hence my proposal to add a meaningful alt to the image and remove the subsequent p.

Does it make sense for you?

Member

anselmh commented Mar 9, 2013

@notabene Mostly true. Point is, we're writing a spec for a long-term time period. That means, the basic markup will be the picture-element without the img-fallback. Then we need alternative text and that again means, our p-element is the proper fallback content.

For the meantime I'd suggest adding the alternative text to the img alt-attribute as well as within the p-element. For not having the alternative text displayed twice, just set the p-element to display: none; in CSS. This hides the text from screenreaders and displays, so everything will be fine.

Hope this is understandable and clarifies you concerns. For the reasons above I am against merging this pull-request but at least one other of the core-members here should vote for / against it. (@marcoscaceres)

we're writing a spec for a long-term time period. That means, the basic markup will be the picture-element without the img-fallback.

Wishful thinking. This has never proved true in the short- and middle-term, sadly. So we have to accommodate older browsers for a long time.

For the meantime I'd suggest adding the alternative text to the img alt-attribute as well as within the p-element. For not having the alternative text displayed twice, just set the p-element to display: none; in CSS. This hides the text from screenreaders and displays, so everything will be fine.

Actually no, this will not be fine: when you don't display images for one reason or another, the img tag is not disabled: it is replaced by its alt. And if someone forgets to add a display:none on picture > p when the next redesign is done, things are going to break apart.

So the img tag is the right fallback to the picture/source stack: sorry I can't seem to explain myself any better, but as is this is going to be redundant.

Member

anselmh commented Mar 12, 2013

Thanks for the feedback! I do think I am not the one to judge here, this should be addressed as an issue and discussed properly by the whole team.

Pmac627 commented Mar 13, 2013

I apologize upfront if I am not supposed to comment on this topic, but I've been watching it for a few days and agree with a side.

I believe the alt attribute should be used as the textual fallback and not the p tag. The logic is two-fold. First, for legacy support, when the older browser ignores the picture and source tags, it naturally uses the img tag. Setting the p tag to display: none is great until you want that text displayed as a fallback in future implementations. The browsers would have to be set to ignore that display: none in cases where it was a child of the picture tag. You could say that the img tag would be omitted ideally in future websites and therefore the p tag would not need the display: none, which could very well be true. It just feels hacky to me.

Second, the img tag and the p tag are handled differently in the DOM, correct? Please correct me if I am mistaken, but the img tag maintains its shape and DOM presence, but puts the alt text within it's borders. So by using a p tag as the fallback, it would alter the layout, forcing designers/developers to create an extra style class to make sure it didn't. Another factor that feels hacky to me.

I hope that makes sense. I simply feel that the alt attribute is an effective way to provide alternate text for images that do not load. If we are concerned about future-proofing the picture element, then perhaps look at adding the alt attribute to the picture tag, rather than incorporating the p tag. The older browser already ignores the picture element so it will also ignore it's attributes, and once the picture tag is recognized and ignores the img tag within it, then the other alt attribute will also be ignored.

I understand both points of view, but I feel the alt method is more semantic.

OK so some quick thoughts, early on I suggested using the picture element as a container for the text alternative, reasons as cited by Ansel. the alt attribute is only used because of the content model of <img> it would have been and would still be better if the text alternative for an img was able to include rich text and other stuff such as lang identifiers. It may be that the putting the alt text in <picture> is a non starter for technical reasons. With <canvas> we have an implemented (in some browsers) model that is similar see http://blog.paciellogroup.com/2012/06/html5-canvas-accessibility-in-firefox-13/ . AT can access the alternative content inside the canvas element. I haven't followed the course of this discussion much so don't feel qualified to comment much more at this point, will need to read up on how it is specced.

Owner

Wilto commented Mar 13, 2013

This example seems to be causing some confusion. This isn’t intended to illustrate that an alt, p specifically, or both can be used to specify fallback content. The idea is that any markup within the tag will be rendered as the fallback in in non-supporting browsers and via a11y tech.

In the majority of cases that will be an img tag, which falls back to the alt attribute’s contents.

If beneficial to the user, however, richer fallback/a11y content can be used—in the case of a complex infographic , for example, the fallback/a11y content could be represented by tabular data. A handful of the W3C’s A11y task force was involved in these talks, and all parties agreed that having this option available stood to have tremendous benefit to end users.

I think illustrating both forms of fallback content in the one markup example is causing some confusion, and the idea that we should be settling on one method or the other. We’ll look into amending these examples.

Thanks for your feedback, guys! Don’t hesitate to let me know if there are any questions or concerns. We couldn’t do this without you!

@Wilto "img tag" ELEMENT you fucker! :-)

Owner

Wilto commented Mar 13, 2013

@stevefaulkner Hey, I’m just glad I managed to avoid using “alt tag”—I do that constantly, for some reason.

Off topic I know but I love the blank stares I get from people who say 'alt-tags' and I correct them to 'alt-attribute'. Like I'm from another planet and have no idea what I'm talking about.

@Wilto thanks for the precisions. In these conditions my pull request is moot, sorry for the noise (although it was useful to raise the potentially confusing examples, as I jumped right into it) ;)

darobin commented Mar 14, 2013

Just a drive-by comment: if the example is regularly causing confusion as @Wilto seems to be saying (and @notabene clearly is), maybe a clearer explanation is needed for it, preferably from someone who was confused by it but now understands? @notabene?

Owner

marcoscaceres commented Mar 14, 2013

Agree with @darobin. @notabene can you please update your pull request?

@marcoscaceres Sure I can, it's a very good idea! I'll just get rid of the img tag entirely and write a richer p.

@darobin you genius. ;)

@marcoscaceres done, can you check if it's less ambivalent?

@marcoscaceres marcoscaceres pushed a commit that referenced this pull request Mar 20, 2013

Marcos Caceres Merge pull request #23 from notabene/gh-pages
Rewrote img-to-p fallback in the examples.
436a738

@marcoscaceres marcoscaceres merged commit 436a738 into ResponsiveImagesCG:gh-pages Mar 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment