> I don't want to change HTML now if I can help it, until it has gone to RFC track
I absolutely agree in all cases -- my purpose in suggesting IMG is that things are reaching the point where some browsers are going to be implementing this feature somehow, even if it's not standard, just because it's the logical next step, and it would be great to have consistency from the beginning -- so that when HTML2 comes along, we're all still in lockstep.....
Wait a minute -- let's temporarily forget about MIME, if it clouds the
issue. My objection was to the discussion of "how are we going to
support embedded images" rather than "how are we going to support
embedded objections in various media".
Otherwise, next week someone is going to suggest 'lets put in a new
tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd">' for audio.
There shouldn't be much cost in going with something that generalizes.
That thread also predicted the weird and unrealistic "let's-stay-inside-the-existing-boundaries" responses:
> SGML does provide an official way of doing this folks
and even if Dan C ain't here to round us up we maybe
ought to stick to the track.
>
> <!ENTITY ICON6 SYSTEM "http://blah..>&ICON6;
Yeah, that looks good, but it would be nice if it had a way to specify different resolution copies of the same image for the future when we have varying screen sizes and varying ppi.
Good proposal though, and hope that this takes off.
You know, there used to be a 'lowsrc' attribute for the image tag. (A lower resolution image, which would be downloaded and displayed before the download of the 'src'-image file.)
It apparently is ignored by most browsers now and no longer allowed in HTML5.
I got a bad feeling about this img tag - what if everyone just uses it to post pictures of cats and people making duck faces?! the internet might be flooded with useless content!
Can't you just scale down to half-size an interlaced gif/jpeg and have the browser intelligently decide to stop downloading once it is at sufficient quality?
"Otherwise, next week someone is going to suggest 'lets put in a new tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd">' for audio. There shouldn't be much cost in going with something that generalizes."
Well, you want to embed the image from a source identified by URL, not refer to it. In fact, I wonder why we need to use href when invoking stylesheets.
Great idea Marc. Just wondering what should happen with images stored on different web servers should someone in the future ever come up with a way for servers to identify individual clients.
Best sort something out now, before people get used to things working in a certain way.
This was the same year that NCSA Mosaic, the first ever web browser, was co-created by Marc Andreessen. He was probably working on Mosaic when he wrote this email.
He says he believes that a Republican administration would be "considerably more open on regulatory issues, and the markets would be more competitive under a Romney administration."
Not to get all political here, but if I could somehow set aside social issues, endorsing Romney (and most republicans) would be a "slam dunk"...but alas,those pesky social issues persist.
"I was proposing to use the file extension (.xbm above) to tag what format the
image was in, but with the intention that in future, when HTTP2 comes along,
the same format negotiation technique would be used to access images."
I'm old enough to remember reading this reposted on usenet (or was it gopher) at the time. Cue discussion about how gopher was much better as it already did images.
There was also serious backlash from certain people (cough TIM BERNERS LEE cough) that adding images to the web would degrade the user experience, encourage bad use cases, and encourage the riffraff to use it.
But it did degrade the user experience, encourage bad use cases, and encourage the riffraff to use it. The easiest way to eliminate those problems is to not have users.
Why'd you have to go making things popular? I could still be using Lynx on a 1200 baud modem!
WorldWideWeb had image support well before this (in a separate window?), and certain included inline images c1993-1994. Seems like an odd thing to do if Tim didn't like them.
I was proposing to use the file extension (.xbm above) to tag what format the image was in, but with the intention that in future, when HTTP2 comes along, the same format negotiation technique would be used to access images.
Nineteen years later and we still don't have HTTP2.
“HTTP2” is a reference to Basic HTTP as defined in 1992. At this point, in early 1993, it was still largely unimplemented. The draft known as “HTTP2” evolved and was eventually standardized as “HTTP 1.0” (albeit not for another three years). HTTP 1.0 did include request headers for content negotiation, a.k.a. “MIME, someday, maybe.”
So, at least in this context, yes, we do have "HTTP2".
It's too bad they went with `img` and `src` instead of listening to Tony Johnson and using `image` and `source`. Saved a few characters for needless abbreviation.
HTML is already very verbose. Although 'header' and 'footer' appear (supposedly) once per page, styling inline elements requires to use 'strong' or the generic 'span' tag. And it's one situation when the tag is numerously repeated, which ends up in a very low signal/noise ratio.
My position may come from the fact that I type every line of code (I have no IDE, just Notepad++). But I think that there aren't enough HTML tags for us to have to use longer names in order to avoid confusion.
«Marc Andreessen (marca@ncsa.uiuc.edu)
Fri, 26 Feb 93 13:32:09 -0800
Tim Berners-Lee writes:
> I don't want to change HTML now if I can help it, until it has gone to RFC track
I absolutely agree in all cases -- my purpose in suggesting IMG is that things are reaching the point where some browsers are going to be implementing this feature somehow, even if it's not standard, just because it's the logical next step, and it would be great to have consistency from the beginning -- so that when HTML2 comes along, we're all still in lockstep.....
Cheers, Marc»
http://1997.webhistory.org/www.lists/www-talk.1993q1/0197.ht...
The HTML 5 designers/implementers fight has always been there, with implementers usually having the last word.
Mark Pilgrim on how much the WHATWG resembles the HTML 2 working group activity: http://web.archive.org/web/20110710091457/http://diveintomar...