Code Monkey home page Code Monkey logo

Comments (9)

tevko avatar tevko commented on June 3, 2024

Without the sizes attribute, the browser assumes the default size, which is 100vw. While a sizes attribute will produce the best result, it's not possible for us to calculate what those sizes should be. It's probably best for the theme developer to handle sizes on their own. The intention of this plugin is to provide a default option to get the user started, without the need for an admin interface. For more information see http://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/

from wp-tevko-responsive-images.

aFarkas avatar aFarkas commented on June 3, 2024

@tevko
Actually, I don't want the plugin to handle/calculate the sizes attribute. I only suggest, that the plugin doesn't add a srcset attribute, if the plugin detects that there is no sizes attribute.

The above css-tricks article starts with an invalid example. As I said if an author uses the srcset attribute with the w descriptor the author must explicitly use the sizes attribute otherwise the markup is invalid.

Additionally to that, we know that the default fallback of 100vw for the sizes attribute isn't good for a general thumbnail filter.

I think this issue can be solved automatically using regular expressions without an admin interface.

from wp-tevko-responsive-images.

tevko avatar tevko commented on June 3, 2024

From the WHATWG spec: "If a source element has a sizes attribute present or an img element has a sizes attribute present, all image candidate strings for that element must have the width descriptor specified." - https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element

From what I understand, this is saying that if a sizes attribute is present, a width descriptor (e.g 300w) must also be present. Not the other way around. Therefore the markup generated by this plugin is completely valid. If we had a sizes attribute and no w descriptor, then we would have invalid markup.

I understand that for something like a thumbnail image, a default size of 100vw isn't very helpful. That's why the sizes attribute exists, and we encourage theme developers to use it. Perhaps some verbiage in the readme files would be in order, making sure theme developers know that they should still add a sizes attribute if possible?

from wp-tevko-responsive-images.

aFarkas avatar aFarkas commented on June 3, 2024

Saying that adding srcset without having sizes "isn't helpful" is an understatement. In fact it is harmful and makes the page invalid.

And correct me if I'm wrong you can detect, whether adding srcset would be harmful or not, by extending the regular expression.

Automatically altering the markup without checking before, whether this is likely helpful or harmful, is evil and destroys the reputation of the responsive image standard.

I read somewhere, that this plugin might be moved into the core. I don't think, that something that does harm the page performance in the first place should be added.

This is also the reason why I commented here.

from wp-tevko-responsive-images.

aFarkas avatar aFarkas commented on June 3, 2024

@tevko
I think it doesn't yield to anything to discuss this further with me. I have pretty strong opinion here. But I would appreaciate it if you would re-talk this issue with the responsive images/issues group.

from wp-tevko-responsive-images.

joemcgill avatar joemcgill commented on June 3, 2024

@aFarkas strong opinions are fine, but in this case, you're simply incorrect. It's perfectly valid HTML to declare a srcset attribute without the corresponding sizes attribute.

Try pasting this example into the W3C validator to confirm:

<!DOCTYPE html>
<html>
<head>
  <title>Test srcset</title>
</head>
<body>
  <img src="small.jpg" srcset="medium.jpg 1000w, large.jpg 2000w" alt="yah">
</body>
</html>

from wp-tevko-responsive-images.

aFarkas avatar aFarkas commented on June 3, 2024

@joemcgill
In short: You are incorrect.

The most important thing: You should not look whether it is valid or invalid, but should ask yourself: Is it responsible to add a srcset without checking whether there is a sizes attribute? Because the following thing is a fact: If the sizes attribute is missing and you render a srcset the result will be worse than having a simple src in about 90% of all cases. This means you really do a lot of harm here. Due to lack of experience in this field about 90% of wordpress user won't even recognize the problem.

If you only write the srcset attribute if the sizes attribute is added by the author on the other hand you know the devloper/author has taken over the responsibility to create a reasonable source size value. It is possible that with this approach some developer will think there is something broken at the first time, but in fact they are forced to do it right. And this is a simple and responsible way to deal with this issue. Another solution to this problem would be to support lazySizes, which will do the complex thing for you.

Now let's talk about your example. I really hate it, because this is basically shown to the developers ... "look how easy it is, do simply this and you are good to go".

<img src="small.jpg" srcset="medium.jpg 1000w, large.jpg 2000w" alt="yah">
  1. A browser is only allowed to choose a candidate from the srcset (There is only one exception). In 90% of time you are using srcset in conjunction with src, the url in the src shouldn't be only a fallback, but should be also listed as a image candidate. This is simply missing in the example above. So small screens will never have the chance to get the "small.jpg".
  2. Omitting sizes attribute can be harmful. In case this was done on purpose, ok... But in case this was done by accident it harms more than it helps (tried to explain above). Therefore it is always a good coding practice to be more explicit with such things.
  3. Missing of sizes attribute is invalid. Believe me or not, it is invalid:

If the srcset attribute has any image candidate strings using a width descriptor, the sizes attribute must also be present, and the value must be a valid source size list.

https://github.com/ResponsiveImagesCG/picture-element/blob/gh-pages/source#L591-L594

from wp-tevko-responsive-images.

joemcgill avatar joemcgill commented on June 3, 2024

@aFarkas

Thank you for further clarifying your concerns. Originally, you made two claims:

a) the markup is invalid

b) let the browser will choose a wrong image candidate. (in most cases a too big one)

Your first claim—seemingly reiterated in your comment above—is the one I was primarily responding to. When you say "the markup is invalid", I (and most web developers) assume you mean that the markup would produce invalid markup when parsed by a browser against the HTML spec.

According to the current spec at whatwg.org, it is perfectly valid HTML to use a srcset without a corresponding sizes attribute. The relevant example in the spec is the first one in the section on viewport-based selection: https://html.spec.whatwg.org/multipage/embedded-content.html#introduction-3:viewport-based-selection-2. The last line reads:

In this example, the sizes attribute could be omitted because the default value is 100vw.

In other words, the sizes attribute is optional. When it is omitted, the browser assumes sizes="100vw". To that end, my understanding is that your first claim is false.

This brings us to your second claim, in which I assume you're arguing that it is harmful to declare a srcset list without the sizes attribute in most cases. That's a perfectly reasonable argument and one that we need to seriously consider, particularly when filtering post_thumbnail_html, which introduces many use cases that don't necessarily apply to images embedded within content. I think we should keep iterating on that piece of the plugin.

By the way – I fully agree with you that the example at css-tricks.com should include small.jpg in the srcset list. We do include all possible sources in the srcset list in this plugin.

from wp-tevko-responsive-images.

aFarkas avatar aFarkas commented on June 3, 2024

@joemcgill
Well, I think you got my main point. happy ;-).

Just some information about validity and the spec issue:
The spec on whatwg was updated on 2015-01-15 and is outdated.

The work on the current spec happens here: https://github.com/ResponsiveImagesCG/picture-element.

Your citation was deleted on 2015-01-16: ResponsiveImagesCG/picture-element@535e96b. And sizes is now a "conditionally required attribute".

So yes, with invalid I meant exactly the same invalid thing you was thinking about. I'm just one day ahead ;-).

from wp-tevko-responsive-images.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.