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:]
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
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
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
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:
, 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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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.
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
* 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
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
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?
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
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
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
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
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
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
32 matches
Mail list logo
