Re: [whatwg] img element comments
On Wed, 6 Aug 2008, Simon Pieters wrote: On Wed, 06 Aug 2008 22:06:33 +0200, Ian Hickson [EMAIL PROTECTED] wrote: meter is probably the right element for this. You can use fallback content in the meter element to show text in legacy browsers that don't support HTML5. [mpt wrote:] And it seems a little excessive to need to construct a canvas when all we want to do is stretch an image horizontally. What you want to do is show a graph, not stretch an image. The image is just the way you've found to do it. However, I don't think it's a valid solution. I don't think this is any more abuse of img than e.g. A group of images that form a single larger picture or An image not intended for the user. You'll notice that the spec has SHOULD-level requirements saying that authors shouldn't do those two things too. You're saying that the meaning of the image is affected by the dimensions at which it is drawn, which seems very dubious since it means you would lose the meaning if you just copied the image, or if you lost the context (the width only means something relative to other widths), etc. A group of images that form a single larger picture would also lose the meaning if you just copied the image, or if you lost the context. That's why it is discouraged. So to reiterate Henri's point, given that browsers (I assume) have to obey disproportionate width= and height= attributes for compatibility with the Web anyway, I don't see the point of requiring authors to make them match the image's proportions. The point is to catch errors (aspect ratio mistakes) when authors are using HTML in a more appropriate manner. Validators can still issue warnings to help with aspect ratio mistakes without putting up a road block for authors trying to migrate to HTML5. The same argument is made for keeping other features, e.g. bgcolor=, cellpadding=, font... If we want the Web to ever become truly media- independent and device-independent, we have to draw a line somewhere. The idea of HTML4 Transitional was to let authors transition to this new world. Well, they've had ten years. Now it's time for the transition to be taken to the next step, and make the deprecated stuff obsolete. I agree that img stretching wasn't explicitly deprecated in HTML4, but it seems pretty clear to me that it's part of the same problem. Moreover, currently the spec bans this, which seems legitimate enough: img src=800x600.jpg width=333 height=250 Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element comments
Ian Hickson wrote on 30/07/08 04:08: On Sun, 14 Oct 2007, Matthew Paul Thomas wrote: On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. https://translations.launchpad.net/ubuntu We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using canvas, so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. As far as I'm aware, the behaviour you describe for w3m matches what all the UAs do. Sorry, I was unclear there. Previously we were using markup like this: img width=35 style=height: 1em; title=Untranslated: 35.42 % alt= 35.42% untranslated src=/@@/red-bar / That gave us the desired result in every browser we cared about, except w3m, which obeys the width= attribute but (because it doesn't do CSS) ignores the style= attribute. So now we include a height= attribute as a fallback: img width=35 style=height: 1em; height=10 title=Untranslated: 35.42 % alt= 35.42% untranslated src=/@@/red-bar / That works in every browser we care about, but would be non-conformant HTML 5 according to the current draft. I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this? Indeed it wouldn't, because canvas wouldn't work in w3m at all! It also wouldn't work when JavaScript was off in any other browser (a serious consideration for our user base). And it seems a little excessive to need to construct a canvas when all we want to do is stretch an image horizontally. So to reiterate Henri's point, given that browsers (I assume) have to obey disproportionate width= and height= attributes for compatibility with the Web anyway, I don't see the point of requiring authors to make them match the image's proportions. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] img element comments
On Wed, 30 Jul 2008, Matthew Paul Thomas wrote: I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this? Indeed it wouldn't, because canvas wouldn't work in w3m at all! Yeah, you're right, canvas wouldn't work particularly well for this. meter is probably the right element for this. You can use fallback content in the meter element to show text in legacy browsers that don't support HTML5. And it seems a little excessive to need to construct a canvas when all we want to do is stretch an image horizontally. What you want to do is show a graph, not stretch an image. The image is just the way you've found to do it. However, I don't think it's a valid solution. You're saying that the meaning of the image is affected by the dimensions at which it is drawn, which seems very dubious since it means you would lose the meaning if you just copied the image, or if you lost the context (the width only means something relative to other widths), etc. So to reiterate Henri's point, given that browsers (I assume) have to obey disproportionate width= and height= attributes for compatibility with the Web anyway, I don't see the point of requiring authors to make them match the image's proportions. The point is to catch errors (aspect ratio mistakes) when authors are using HTML in a more appropriate manner. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element comments
On Wed, 06 Aug 2008 22:06:33 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 30 Jul 2008, Matthew Paul Thomas wrote: I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this? Indeed it wouldn't, because canvas wouldn't work in w3m at all! Yeah, you're right, canvas wouldn't work particularly well for this. meter is probably the right element for this. You can use fallback content in the meter element to show text in legacy browsers that don't support HTML5. And it seems a little excessive to need to construct a canvas when all we want to do is stretch an image horizontally. What you want to do is show a graph, not stretch an image. The image is just the way you've found to do it. However, I don't think it's a valid solution. I don't think this is any more abuse of img than e.g. A group of images that form a single larger picture or An image not intended for the user. You're saying that the meaning of the image is affected by the dimensions at which it is drawn, which seems very dubious since it means you would lose the meaning if you just copied the image, or if you lost the context (the width only means something relative to other widths), etc. A group of images that form a single larger picture would also lose the meaning if you just copied the image, or if you lost the context. So to reiterate Henri's point, given that browsers (I assume) have to obey disproportionate width= and height= attributes for compatibility with the Web anyway, I don't see the point of requiring authors to make them match the image's proportions. The point is to catch errors (aspect ratio mistakes) when authors are using HTML in a more appropriate manner. Validators can still issue warnings to help with aspect ratio mistakes without putting up a road block for authors trying to migrate to HTML5. -- Simon Pieters Opera Software
Re: [whatwg] img element comments
On Wed, 06 Aug 2008 22:42:09 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Validators can still issue warnings to help with aspect ratio mistakes without putting up a road block for authors trying to migrate to HTML5. Moreover, currently the spec bans this, which seems legitimate enough: img src=800x600.jpg width=333 height=250 -- Simon Pieters Opera Software
Re: [whatwg] img element comments
The element you are describing is effectively a progress bar control. It is still not present in HTML; however, it can be emulated using an OUTPUT control with layout or with invisible text and a custom background: SPAN STYLE=COLOR: RED; BACKGROUND: RED; BORDER: THIN SOLID BLACK ***/SPAN Alternatively, if you scorn at the number of asterisks, you can use INPUT TYPE=TEXT SIZE=13 DISABLED. This has the disadvantage of being irrelevant to screen readers. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, July 30, 2008 5:08 AM To: Matthew Paul Thomas Cc: WHATWG Subject: Re: [whatwg] img element comments On Sun, 14 Oct 2007, Matthew Paul Thomas wrote: On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. https://translations.launchpad.net/ubuntu We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using canvas, so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. As far as I'm aware, the behaviour you describe for w3m matches what all the UAs do. I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this?
Re: [whatwg] img element comments
Kristof Zelechovski writes: The element you are describing is effectively a progress bar control. It is still not present in HTML HTML 5 introduces progress for that: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html#the-progress Smylers
Re: [whatwg] img element comments
On Sat, 13 Oct 2007, Henri Sivonen wrote: On Oct 13, 2007, at 01:55, Ian Hickson wrote: On Tue, 7 Nov 2006, Henri Sivonen wrote: So I think width and height should not have conformance requirements tied to pixel dimensions of the references image file. They are presentational, but they are such a useful presentational optimization that I think it doesn't make sense to try the get rid of that presentationalism just to comply with a principle. Is the compromise in the spec today acceptable? I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. It solves the problem of authors not being informed when they give the wrong dimensions by mistake and end up screwing up the ratio. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element comments
On Sun, 14 Oct 2007, Matthew Paul Thomas wrote: On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. https://translations.launchpad.net/ubuntu We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using canvas, so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. As far as I'm aware, the behaviour you describe for w3m matches what all the UAs do. I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element comments
On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: ... I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. ... As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. https://translations.launchpad.net/ubuntu We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using canvas, so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] img element comments
On Oct 13, 2007, at 01:55, Ian Hickson wrote: On Tue, 7 Nov 2006, Henri Sivonen wrote: So I think width and height should not have conformance requirements tied to pixel dimensions of the references image file. They are presentational, but they are such a useful presentational optimization that I think it doesn't make sense to try the get rid of that presentationalism just to comply with a principle. Is the compromise in the spec today acceptable? I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] img element comments
On Sat, 4 Nov 2006, Anne van Kesteren wrote: On Sat, 04 Nov 2006 07:37:32 +0100, Ian Hickson [EMAIL PROTECTED] wrote: * It should probably mention 'img.src = foo' (that loading directly starts). I thought that 'img.setAttribute(src, foo)' even did different things in browsers (when the element is not yet inserted into the document) so reflect might not be accurate. I couldn't find a difference. Any idea what it was? From what I recall setting the DOM attribute on a newly created element (not appending it to the DOM) would cause download immediately in all browsers, but some browsers acted differently when the src content attribute was set on the newly created element. As in, the download started the moment it was appended to the DOM, not before (no load event would fire). Is this required for compat or can we leave it as is? How widely is it implemented? * The height and width attributes as defined are completely presentational. I don't really see any value in keeping them. Now I suppose they have to be supported anyway, but so does body bgcolor=. I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? If you require this only for images with known intrinsic dimensions than that would be fine with me (as in, for some cases of SVG the requirements are likely different). Is the way it is phrased now acceptable? On Sat, 4 Nov 2006, Henri Sivonen wrote: What about non-square pixels in the image file? Both GIF and PNG allow pixel aspect ratios other than 1:1. I don't have test cases and I don't know what browsers do. The spec sidesteps this by defining the dimensions as CSS pixels. Also, such a requirement would make document conformance dependent on resources other than the (X)HTML5 file itself. Is that a good idea? Is the document conforming, not conforming or undecided if there are no other errors but the image cannot be retrieved? I think we're going to have to work this out -- maybe there should be two things, document conformance and related resource conformance. What image formats should a conformance checker know about? GIF, PNG and JFIF? Same as browsers, I guess. On Tue, 7 Nov 2006, Shadow2531 wrote: Yeh, in example method, this is the suggestion: (at least from what I got out of the proposal) [conforming] img src=276x110.png alt=fallback text title=description img src=276x110.png width=276 height=110 alt=fallback text title=description [non-conforming] img src=276x110.png width=400 height=200 alt=fallback text title=description img src=276x110.png width=50% height=50% alt=fallback text title=description Agreed. img src=276x110.png width=276 alt=fallback text title=description This is fine in the spec as it is today. On Tue, 7 Nov 2006, Andreyka Lechev wrote: Don't forget that percentage values are relative values. And in current browser implementations, setting those values via CSS-rules or using width- and height-attributes are leading to different results! It's due to different parents to calculate actual (pixel) values from! This doesn't seem to be true. CSS values are relative to the the parent element in HTML tree: div style=width: 100px; height: 100px; img src=276x110.png style=width: 50%; height: 50%; /div = displays image 50x50px. Attributes values are relative to the actual size of the image: img src=276x110.png width=50% height=50% = displays image 138x55px. That may be very useful in many cases, so as a HTML-coder, I don't think anybody should change that behavior without proposing something to replace it. I couldn't reproduce the behaviour you give above. Do you have test cases showing this? On Tue, 7 Nov 2006, Greg Kilwein wrote: Also, if only one of either the width or height attributes is set, some browsers will scale the other dimension automatically. Consider this example: img src=100x50.png width=50 Some browsers will scale height to be 25 in this instance, given an image with a width of 100 pixels and a height of 50 pixels. This is quite useful when the height or width of an image needs to be fixed without distorting the aspect ratio. This will be defined in the rendering section in due course. On Sat, 4 Nov 2006, Matthew Raymond wrote: Lachlan Hunt wrote: The style attribute is far more presentational than the height and width attributes. I don't see how either is more or less presentational. The |height| and |width| attributes are entirely presentational, since their sole purpose is to define the sizing of the image in the document layout. I agree that style=height: 100px is different from height=100 only in a syntactical fashion, from a semantic standpoint. On Sun, 5 Nov 2006, Lachlan Hunt wrote: Using attributes
Re: [whatwg] img element comments
Clarification- never explicitly defined should probably be never explicitly 'limited' The W3C documents seem to require support for, at least, GIF, JPEG, MNG and PNG. Apologies if this is just nit-picking. [I'll regret saying this, but I wonder if the list can be pruned with the expiration of the GIF patents.] BdG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Thursday, 2007 August 16 00:06 To: Ian Hickson Cc: WHATWG Subject: Re: [whatwg] img element comments Ian Hickson wrote: On Sat, 4 Nov 2006, Lachlan Hunt wrote: And, as I mentioned in IRC, I think it should be defined that the value should resolve to a valid URI for an image, so that img src= alt= isn't conforming, except in this rare case: p xml:base=foo.pngimg src= alt=//p Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and Opera respectively support those.) I think you're putting too much emphasis on the words for an image in what I wrote. I think my intention was to avoid cases where it's pointing to itself. In practical terms, it just needs to point to file in a format that browsers support for img, but HTML has never explicitly defined which image formats browsers should or should not support, and I don't think it should. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] img element comments
On Sat, 4 Nov 2006, Lachlan Hunt wrote: Ian Hickson wrote: On Fri, 3 Nov 2006, Anne van Kesteren wrote: * It should probably mention 'img.src = foo' (that loading directly starts). I thought that 'img.setAttribute(src, foo)' even did different things in browsers (when the element is not yet inserted into the document) so reflect might not be accurate. I couldn't find a difference. Any idea what it was? I don't know of any difference and I don't think there should be any, even if some implementations currently do. It would only be confusing for authors if they behaved differently. Agreed. * I would also suggest to put If the src attribute is omitted, there is no alternative image representation. after the last statement on the alt attribute. Done. (I think. I edited a bunch of stuff before reading your comment so it may be not quite what you meant.) And, as I mentioned in IRC, I think it should be defined that the value should resolve to a valid URI for an image, so that img src= alt= isn't conforming, except in this rare case: p xml:base=foo.pngimg src= alt=//p Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and Opera respectively support those.) If we allow SVG, it's trivial to send XHTML as image/svg+xml and the processing is as defined then for HTML as for SVG, so why exlude HTML? If we disallow SVG, what's the definition? image/* that corresponds to a non-interactive bitmapped resource? What about WMFs? Why would those be disallowed? As Simon asked on IRC, who are we helping by limiting what's allowed? * I think it would also make sense to show some more examples for the alt attribute. http://www.cs.tut.fi/~jkorpela/html/alt.html might be too large to be included in the specification, but guidelines to that effect would be more than welcome. Noted. The explanations you've written in this are good also. http://hixie.ch/advocacy/alttext The house example under argument #3 would be good to include. I've gone through both those documents and made the spec cover the points made therein. Let me know if I missed anything useful. * The height and width attributes as defined are completely presentational. I don't really see any value in keeping them. Now I suppose they have to be supported anyway, but so does body bgcolor=. I disagree. Specifying the size is very good for incremental rendering, but the alternatives are awful. The spec now allows sizes to be given (though not %s). * Perhaps we can allow content for XML documents? That's tempting. We'd have to allow it for HTML too (via DOM manipulation). It's already possible via DOM manipulation (except in IE which throws an exception). The spec should at least define what it means and how to process it, even if it's defined that UAs should just ignore it. I've not gone there yet, this may be a little too radical for its own good. The serialisation problems alone would be confusing to many. Authors have object for the advanced fallback if they need it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element comments
At 10:48 + 15/08/07, Ian Hickson wrote: * I would also suggest to put If the src attribute is omitted, there is no alternative image representation. after the last statement on the alt attribute. Done. (I think. I edited a bunch of stuff before reading your comment so it may be not quite what you meant.) And, as I mentioned in IRC, I think it should be defined that the value should resolve to a valid URI for an image, so that img src= alt= isn't conforming, except in this rare case: p xml:base=foo.pngimg src= alt=//p Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and Opera respectively support those.) If we allow SVG, it's trivial to send XHTML as image/svg+xml and the processing is as defined then for HTML as for SVG, so why exlude HTML? If we disallow SVG, what's the definition? image/* that corresponds to a non-interactive bitmapped resource? What about WMFs? Why would those be disallowed? As Simon asked on IRC, who are we helping by limiting what's allowed? Making life a little easier for the browser implementers in what they might reasonably expect to find there? Clearly images have to have a visual representation. Embedding only audio, or ancillary data, here would be too weird. Perhaps images are things that are non-temporal and with visual representation, or slightly temporal in the sense of animated GIFs etc. where temporal control etc. is not expected or desired. They probably do not have associated audio, perhaps? That means that a 'static' SVG image is indeed an image, whereas an SVG presentation that has 'significant' temporal behavior is video. I'm not sure what to say about interactivity; SVG allows it, so probably it's allowed. But then, why isn't an HTML page embeddable in image? It has a visual representation, and if we allow interactivity, it would seem to fit. Similarly using SMIL to layup something that was 'static' (perhaps several images overlayed in regions) would seem to also be allowed. Hm. More principles, someone? -- David Singer Apple/QuickTime
Re: [whatwg] img element comments
Hi, p xml:base=foo.pngimg src= alt=//p Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and Opera respectively support those.) snip As Simon asked on IRC, who are we helping by limiting what's allowed? Displaying PDF is great for company web-apps (mine uses it extensively, saving us lots of time). Bert Who'd like to see the mailto command to support attachments (so not only an e-mail can be generated from a web-app, but attachments such as pdf files can be included).
Re: [whatwg] img element comments
Le 7 nov. 2006 à 14:28, Greg Kilwein a écrit :
Also, if only one of either the width or height attributes is
set, some browsers will scale the other dimension automatically.
Consider this example:
img src=100x50.png width=50
Some browsers will scale height to be 25 in this instance, given an
image with a width of 100 pixels and a height of 50 pixels. This
is quite useful when the height or width of an image needs to be
fixed without distorting the aspect ratio.
You can also do this from a stylehseet in most browsers:
img { width: 50px; height: auto; }
although this works only if the height attribute is not present on
the image. Personally, I often like to use:
img { max-width: 100%; height: auto; }
but again it doesn't work when the height attribute is set, which is
somewhat silly if you see this attribute as metadata about the linked
file while it makes perfect sense if you consider the height
attribute as the desired height of the image on the page.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] img element comments
On Tue, 07 Nov 2006 03:49:40 +0100, Matthew Paul Thomas [EMAIL PROTECTED] wrote: In 1998 I used a version of iBrowse for the Amiga that treated img width= and height= in the way Ian proposed -- as preliminary advice on the dimensions of the image, reflowing if the actual dimensions turned out to be different. I thought the proposal was that only that (setting height and width to the intrinsic size of the image) would be conforming, but that rendering would still be the same. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] img element comments
On Nov 4, 2006, at 08:37, Ian Hickson wrote: I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? Suppose there are desktop systems in the near future that double the pixel density of the display compared to what is common today. Considering the handheld displays Nokia ships, I guess it is only a matter of time for similarly small pixels to appear in desktop-sized panels at affordable prices. Apple already seems to be preparing for this. To render legacy pages, browsers will probably have to define 1 CCS px to be equal to two device pixels and render each image pixel of legacy bitmaps as 2 by 2 device pixels. Now if an author wants to deliver more precision to such new systems while being compatible with legacy systems, the reasonable thing to do is leaving the width and height attributes to values that would make sense for legacy systems and to quadruple the number of samples in the bitmap by doubling its pixel height and width. So I think width and height should not have conformance requirements tied to pixel dimensions of the references image file. They are presentational, but they are such a useful presentational optimization that I think it doesn't make sense to try the get rid of that presentationalism just to comply with a principle. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] img element comments
On 11/7/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
I thought the proposal was that only that (setting height and width to the
intrinsic size of the image) would be conforming, but that rendering would
still be the same.
Yeh, in example method, this is the suggestion:
(at least from what I got out of the proposal)
[conforming]
img src=276x110.png alt=fallback text title=description
img src=276x110.png width=276 height=110 alt=fallback text
title=description
[non-conforming]
img src=276x110.png width=400 height=200 alt=fallback text
title=description
img src=276x110.png width=50% height=50% alt=fallback text
title=description
img src=276x110.png width=276 alt=fallback text title=description
Note: For backwards-compatibility, even though these are
non-conforming, the width and or height attribute values are still
applied to the image for rendering (if css doesn't override).
[encouraged if you need to resize the image]
selectorThatMatchesTheImage {
width: 400px;
height: 200px;
}
img src=276x110.png width=276 height=110 alt=fallback text
title=description
[encouraged if you need to resize the image - alt]
img src=276x110.png style=width: 50%; height: 50%; width=276
height=110 alt=fallback text title=description
If that's correct, doing things the proposed, encouraged, conforming
way seems fine as far as UAs that support css are concerned.
--
burnout426
Re: [whatwg] img element comments
On 07.11.2006, at 19:49, Shadow2531 wrote: On 11/7/06, Anne van Kesteren [EMAIL PROTECTED] wrote: I thought the proposal was that only that (setting height and width to the intrinsic size of the image) would be conforming, but that rendering would still be the same. [encouraged if you need to resize the image - alt] img src=276x110.png style=width: 50%; height: 50%; width=276 height=110 alt=fallback text title=description If that's correct, doing things the proposed, encouraged, conforming way seems fine as far as UAs that support css are concerned. Don't forget that percentage values are relative values. And in current browser implementations, setting those values via CSS-rules or using width- and height-attributes are leading to different results! It's due to different parents to calculate actual (pixel) values from! CSS values are relative to the the parent element in HTML tree: div style=width: 100px; height: 100px; img src=276x110.png style=width: 50%; height: 50%; /div = displays image 50x50px. Attributes values are relative to the actual size of the image: img src=276x110.png width=50% height=50% = displays image 138x55px. That may be very useful in many cases, so as a HTML-coder, I don't think anybody should change that behavior without proposing something to replace it. -- Andreyka Lechev [EMAIL PROTECTED]
Re: [whatwg] img element comments
Andreyka Lechev wrote: On 07.11.2006, at 19:49, Shadow2531 wrote: On 11/7/06, Anne van Kesteren [EMAIL PROTECTED] wrote: I thought the proposal was that only that (setting height and width to the intrinsic size of the image) would be conforming, but that rendering would still be the same. [encouraged if you need to resize the image - alt] img src=276x110.png style=width: 50%; height: 50%; width=276 height=110 alt=fallback text title=description If that's correct, doing things the proposed, encouraged, conforming way seems fine as far as UAs that support css are concerned. Don't forget that percentage values are relative values. And in current browser implementations, setting those values via CSS-rules or using width- and height-attributes are leading to different results! It's due to different parents to calculate actual (pixel) values from! Also, if only one of either the width or height attributes is set, some browsers will scale the other dimension automatically. Consider this example: img src=100x50.png width=50 Some browsers will scale height to be 25 in this instance, given an image with a width of 100 pixels and a height of 50 pixels. This is quite useful when the height or width of an image needs to be fixed without distorting the aspect ratio. -- Greg Kilwein [EMAIL PROTECTED]
Re: [whatwg] img element comments
Lachlan Hunt wrote: Using attributes to describe actual metadata about an image that has real practical benefits, for both the author and user, is not presentational in my view. Yes, but that is not what the height and width attributes are. They say nothing about the image and everything about the size at which the image is drawn. There's even an edge case where specifying incorrect dimensions could still be considered semantic. Unfortunately, I can't find the site I'm thinking of, but I've seen a site somewhere that created art by using small images and stretching them for the pixelation effect. In this case, stretching the image is part of the artwork's artistic value and meaning, not just it's presentation, and it would lose it all if the image were shown at it's actual size. There are always edge cases. The distinction between semantics and presentation is a fuzzy one. Nonetheless, I think most of the time height and width as specified on today's img tags are clearly presentational. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] img element comments
* The height and width attributes as defined are completely
presentational. I don't really see any value in keeping them. Now I
suppose they have to be supported anyway, but so does body bgcolor=.
I disagree. Specifying the size is very good for incremental rendering,
but the alternatives are awful.
+1 on that.
1. img ... style=height: 100px; width: 100px;
The style attribute is far more presentational than the height and width
attributes.
2. img ... id=foo
#foo { height: 100px; width: 100px; }
This is simply not feasible in most cases, unless there are very few
images on the site. Think about flickr, it just wouldn't be possible to
specify the dimensions of all their images in a stylesheet.
Another thing is that with height and width attributes information
about image size is
available at once, when in case of CSS it is available only after
stylesheet file is loaded
and parsed.
As for style=... I wish there wasn't such thing...
Regards,
Rimantas
--
http://rimantas.com/
Re: [whatwg] img element comments
On Nov 4, 2006, at 08:37, Ian Hickson wrote: I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? What about non-square pixels in the image file? Both GIF and PNG allow pixel aspect ratios other than 1:1. I don't have test cases and I don't know what browsers do. Also, such a requirement would make document conformance dependent on resources other than the (X)HTML5 file itself. Is that a good idea? Is the document conforming, not conforming or undecided if there are no other errors but the image cannot be retrieved? What image formats should a conformance checker know about? GIF, PNG and JFIF? Sniffing the pixel dimensions (without the aspect ratio) out of GIF or PNG is both easy and efficient if the conformance checker can assume that image files are conforming and don't need to be fully decoded. JFIF looks harder. * Perhaps we can allow content for XML documents? That's tempting. We'd have to allow it for HTML too (via DOM manipulation). I'm not sure, though. object is pretty buggy, wouldn't this just cause img to get those bugs? Also, it would cause further divergence between the serializations... -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] img element comments
Ian Hickson [EMAIL PROTECTED] wrote: [width and height attribute on the img element] I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? Definitely on the integer value only, allowing percentage values makes no sense to me. In some cases I have used just one attribute http://homepage.ntlworld.ie/spartanicus/fit_image_in_column2.htm , but on examination this does not only have no benefit, it needlessly causes the single coded image size to be reserved in the flow if for example a graphical client is configured to not initially retrieve images. When omitting both attributes the element's size collapses to the size of the alt content, whilst the reflow on a possible subsequent retrieval of the image occurs anyway in this particular scenario. Meanwhile allowing authors to omit width height together caters for situations where better functionality is achieved if the natural dimension of the image isn't reserved on the initial flow layout. The required reflow on a subsequent retrieval of the image can be considered preferable compared to the alternative where potentially valuable screen space may be wasted to reserve space in the initial flow for the natural size of the image. So I also support requiring both to be present if either is present. But wouldn't requiring the width height values to be equal to the natural dimension of the image require conformance checkers to have a capability to parse images to retrieve these values? -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] img element comments
On Fri, 03 Nov 2006 19:38:37 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: * Regarding the alt attribute, wouldn't it make sense to just allow it to be omitted? In terms of meaning it seems the same. I have always considered requiring the alt attribute resulting in the use of alt= as an anomaly. On the other hand, it probably shows the difference between people who thought of the alternative representation and people that haven't. Many authoring tools generate alt= by default, mine does. It is then up to the coder to do the right thing, but the tool will frequently not prompt him to do so. For that reason I don't think that the presence of alt= can reasonably be considered as having been a conscious decision. I'm note sure if a UA treating the absence of an alt attribute differently from alt= would benefit a user. Alexey Feldgendler [EMAIL PROTECTED] wrote: The problem with allowing omission of alt depends on the meaning of img without alt. If img without alt is defined to mean the same as img with alt=, then the problem is that all cases when people omit the alt attribute because they don't care will end up with mangled meaning. I don't see that as changing anything. Documents containing content images without alt content are broken regarding this aspect, and they will remain so if img without an alt attribute is considered equal to img elements with alt=. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] img element comments
On Sat, 04 Nov 2006 12:37:32 +0600, Ian Hickson [EMAIL PROTECTED] wrote: * The height and width attributes as defined are completely presentational. I don't really see any value in keeping them. Now I suppose they have to be supported anyway, but so does body bgcolor=. I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? The use case is giving the UA information on the dimensions of the image before the image has been downloaded, the same as the type= or hreflang= attributes on the link element give information on the resource before the resource is fetched. That's how these attributes could have been defined if we were designing HTML from scratch. In today's browsers, specifying width and height on img different from the actual dimensions of the image forces the image to be resized for display. There is existing content which relies on this. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] img element comments
On Sat, 04 Nov 2006 12:42:34 +0600, Ian Hickson [EMAIL PROTECTED] wrote: If img without alt is defined to mean that the image is semantically valuable but without an alternative text, then the problem is that we need to distinguish between empty and omitted alt in DOM somehow. That's easy enough; the real problem is that we end up saying that literally billions of img tags are semantically valuable when in all likelihood they're just decorative images. The number of img tags with a alt= attribute is about half the number of img tags with a src= attribute. (1) There are also many img tags with alt= which are actually semantically valuable (2), where alt= has been inserted automatically by the authoring tool or manually by the author just to make the document pass formal validation. I can't say whether (1) or (2) is more widespread. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] img element comments
On Sat, 04 Nov 2006 19:43:02 +0600, Spartanicus [EMAIL PROTECTED] wrote: The problem with allowing omission of alt depends on the meaning of img without alt. If img without alt is defined to mean the same as img with alt=, then the problem is that all cases when people omit the alt attribute because they don't care will end up with mangled meaning. I don't see that as changing anything. Documents containing content images without alt content are broken regarding this aspect, and they will remain so if img without an alt attribute is considered equal to img elements with alt=. img is somewhat broken in any case. If I was making it up from scratch, I would treat missing alt same as alt= and define it to mean semantically valuable image for which the author did not provide an alternative text. For purely decorative images, if such thing is to exist at all, I would define a separate attribute like decorative, so that semantic images surely don't end up as decorative by mistake. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] img element comments
Lachlan Hunt wrote:
I disagree. Specifying the size is very good for incremental rendering,
but the alternatives are awful.
1. img ... style=height: 100px; width: 100px;
The style attribute is far more presentational than the height and width
attributes.
I don't see how either is more or less presentational. The |height|
and |width| attributes are entirely presentational, since their sole
purpose is to define the sizing of the image in the document layout.
They do not give the dimensions of the image itself, nor could you
define them in such a way without breaking pages. Therefore, the |style|
attribute with width and height properties, however undesirable, is no
worse than using |width| and |height| attributes.
2. img ... id=foo
#foo { height: 100px; width: 100px; }
This is not entirely true:
| img src=foo
| img[src=foo] { height: 100px; width: 100px; }
And the above will style all instances of the image, not just the one
with the |id| foo.
However, even if this weren't the case, and you has to use |id|, if
we're talking about images that have non-presentational value and their
own unique dimensions, aren't we also talking about content that we
might want to link to directly rather than simply linking to the
containing page?
This is simply not feasible in most cases, unless there are very few
images on the site. Think about flickr, it just wouldn't be possible to
specify the dimensions of all their images in a stylesheet.
You can specify the sizes in an additional style element. The
primary site styling will be in a separate CSS file, while the
page-specific (and image-specific) styling can remain in the document,
and therefore can be dynamically generated on the server. (Not to
mention that the style sheet itself could be dynamically generated on
the server, although that would negatively impact caching.)
Also, Flickr is a bad example, because when you perform a search,
images often have widths and heights of 240, so you could use a |class|
attribute on the images that sets the initial styling...
| thumbnail { height: 240px; width: 240px; }
...and then you only have to set at most one CSS property per thumbnail
image.
Re: [whatwg] img element comments
Michel Fortin wrote: Except that, contrary to bgcolor, the height and width attributes can help solve a real problem: page jiggling while the images loads. It's somewhat like the type=image/jpg attribute you can set for links: it gives advance information on what the external content is supposed to be. So does CSS, as you point out below. In this case, height and width are inherent properties of the document if we consider the linked image as part of the document, much alike the type= attribute on a link. I'm not sure what you mean. The |type| attribute describes the MIME type. Even if you were to deliberately manipulate this value to some end, I don't see how you could do so in a way that alters the presentation of the document like |height| and |width| do, with the one exception being that you can prevent a style sheet from loading by intentionally giving the wrong |type| value. Of course, there's no obvious motive for providing a link that does nothing, is there? Sure, we could use style=width: 32; height: 32 instead of width=32 height=32, but most of the time the size of an image isn't a matter of style, it's a matter of what the image is. The |width| and |height| attributes don't specify the dimensions of the source image. They specify the size of the image in the document. That's presentational, in my book. Arguing that those attributes are properties of the image within the document amounts to a free pass for all presentational markup. The font, center, s and u elements communicate a property of the text, not the presentation. I don't buy it. Without the attributes actually describing a property of the source image (which is redundant), the |height| and |width| have no semantic meaning. Convenient as they are, they're styling as markup.
