Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 1:46 PM, Adam Barth wrote: > On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor > > > wrote: > > On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison > wrote: > >> There is no legitimate reason that non-developers would need to paste > >> "javascript:" URLs into the addressbar, and the ability to do so > >> should be disabled by default on all browsers. > > > > Sure there is: bookmarklets, basically. javascript: URLs can do lots > > of fun and useful things. Also fun but not-so-useful things, like: > > > javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); > > > > (Credit to johnath for that one. Repeat with 0 instead of 180deg to > > undo.) You can do all sorts of interesting things to the page by > > pasting javascript: URLs into the URL bar. Of course, there are > > obviously security problems here too, but "no legitimate reason" is > > much too strong. > > We could allow bookmarklets without allowing direct pasting into the > URL bar. That would make the social engineering more complex at > least. > > Adam > Would a pop-up warning be sufficient, rather than disallowing it? For example, if I write the following URL into Firefox... http://char...@49research.com/ ... Firefox will pop-up a modal dialog box with the following message... > You are about to log in to the site "49research.com" with the username > "charles", but the website does not require authentication. This may be an > attempt to trick you. > > Is "49research.com" the site you want to visit? > > [yes] [no] > Perhaps a modal dialog box could pop-up for copy-and-pasted JavaScript URLs to (after the user presses enter). -- Charles Iliya Krempeaux, B.Sc.
Re: [whatwg] Will you consider about RFC 4329?
Hello, On Mon, Apr 5, 2010 at 6:11 AM, Swampert wrote: > > Dear WHATAG, > In your HTML5 draft standard, the default value for type attribute in script > element is "text/javascript". While according to RFC 4329, the MIME type > "text/javascript" > is obsolete, the proper MIME type for JavaScript is "application/javascript" > or "application/ecmascript". And Apache also can serve .js files as > application/javascript MIME > type. And JavaScript is obviously somewhat a kind of application, we already > serve XHTML1.1/XHTML5 webpages as application/xhtml+xml, why don't we use > application/* on JavaScript? Isn't the reason that XML (including XHTML) changed from the text/* MIME types to the application/* MIME types have to do with problems that occurred with Character Transcoding that automagically happens from Transcoding Proxies when the HTTP Content-Type is give as a text/* MIME type?! Specifically, the issue that occurs when an XML document (explicitly or implicitly) declares an encoding different than the Content-Type (explicitly or implicitly) declared by HTTP?! I.e., I don't think they are choosing application/* MIME types because JavaScript is "a kind of application". (Not that the "application/*" MIME type actually means that the file, with said MIME type, is "a kind of application".) -- Charles Iliya Krempeaux, B.Sc. http://changelog.ca/ Everything a Web Developer or Web Designer Should Know - http://w3remix.com/
[whatwg] Video Element Events? - Use Case: Custom Progress Bar
Hello,
(Sorry if this has come up before and I missed it.)
I was looking over the spec and looking to see how I'd go about creating a
custom "progress bar". (Like you see as part of "scrub bars".)
To do this I'd imagine that a playing video would have to "send out" events
"fast enough" so that the progress bar could be updated "enough".
Perhaps I didn't read the spec carefully enough, but I don't see any such
event.
I'd expect to be able to do something like...
videoElem = document.getElementById("aVideoElement");
videoElem.addEventListener( "moment",
function()
{
// Handle the event.
// I.e., update the progress bar or something.
//
// I'll need a way to know a what point in time the video is at now.
}
,false);
Note I used the fictitious "moment" event. (I doesn't have to be called
"moment". I just made up something.)
*Is there anything like this already?*
Or do you just set up a timer and poll the "currentTime" attribute.
I.e., something like...
function updateProgressBar(id)
{
videoElem = document.getElementById(id);
// Update the progress bar using: videoElem.currentTime
}
setTimeout("updateProgressBar(\"aVideoElement\")", 100);
I suppose the advantage of the polling method is that you can specify how
often you do the update. But it doesn't seems to make for poorer developer
usability.
--
Charles Iliya Krempeaux, B.Sc.
http://ChangeLog.ca/
Re: [whatwg] Video : Slow motion, fast forward effects
Hello Ian, On Wed, Oct 15, 2008 at 2:08 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > Regarding whether to play audio while rewinding: > > Leaving this be something that is optional doesn't make sense to me. Could we make it configurable though?... So... the web developer could check if playing sound for this is available. And if it is available, they can turn it on (if they wanted to). And if it is not available, they can "handle" it in some way. (Which could even be a message to the user saying that feature is not available.) Thanks. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/
Re: [whatwg] Video : Slow motion, fast forward effects
Hello, Note that I said "when it is available". I'd strongly encourage Codec/Plugin developers to add support for it. As I know you'll have a certain class of web developers screaming for this feature. (And you'll be able to create alot of "cool" stuff with it :-) ) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ On Tue, Oct 14, 2008 at 12:34 PM, WeBMartians <[EMAIL PROTECTED]>wrote: > I agree that scrubbing requires non-1X audio. However, to require it is > going to cause CoDec/PlugIn developers not just headaches > but maybe aneurisms as well. > > Interestingly enough, audio at varied play rates has the potential to > retain tonality. Since the audio is encoded with something > like a Fourier transform, the data is "spectral" rather than "wave." The > samples may be presented tonally-accurate even if their > duration is not 1:1. > > Nonetheless, you're going to be very unpopular if the word "required" > starts showing up. > > Best! > ____ > > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux > Sent: Tuesday, 2008 October 14 15:24 > To: Ian Hickson > Cc: [EMAIL PROTECTED] > Subject: Re: [whatwg] Video : Slow motion, fast forward effects > > Hello Ian, > > On Mon, Oct 13, 2008 at 3:41 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > [...] > >On Thu, 7 Aug 2008, Charles Iliya Krempeaux wrote: > >> >> This feature would be used to implement "scrubing". Like what you > see >> in Non-Linear Editors... for making movies, etc. (I.e., grabbing > the >> "position handle" of the player, and moving it forwards and > backwards >> through the video, and varying speeds, to find what you are > looking >> for.) >> >> In those types of applications, the audio is on. And it is > important >> for usability, for the video editor to hear the sound. > > >I agree that on the long term we would want to provide this, but I > think >that is something we should offer as a separate feature (e.g. a flag > that >decides whether reverse-playback audio is muted or not, defaulting > to true >for compatibility with today). > > If there's some way of turning this feature "on" (when it is available)... > that would be sufficient for scrubbing AFAICT. > -- > Charles Iliya Krempeaux, B.Sc. > http://ChangeLog.ca/ > >
Re: [whatwg] Video : Slow motion, fast forward effects
Hello Ian, On Mon, Oct 13, 2008 at 3:41 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: [...] > On Thu, 7 Aug 2008, Charles Iliya Krempeaux wrote: > > > > This feature would be used to implement "scrubing". Like what you see > > in Non-Linear Editors... for making movies, etc. (I.e., grabbing the > > "position handle" of the player, and moving it forwards and backwards > > through the video, and varying speeds, to find what you are looking > > for.) > > > > In those types of applications, the audio is on. And it is important > > for usability, for the video editor to hear the sound. > > I agree that on the long term we would want to provide this, but I think > that is something we should offer as a separate feature (e.g. a flag that > decides whether reverse-playback audio is muted or not, defaulting to true > for compatibility with today). > If there's some way of turning this feature "on" (when it is available)... that would be sufficient for scrubbing AFAICT. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/
Re: [whatwg] Whatwg Social Meeting This Month
When you have a meeting in Vancouver, let me know :-) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ On Tue, Oct 14, 2008 at 8:28 AM, Michael Carter <[EMAIL PROTECTED]>wrote: > Hello, > > Who is interested in a whatwg social meeting this month? While I know many > of you are located all around the world, if there is a locus of participants > in whatwg, I would say its in the Bay Area (San Francisco and perimeter, CA, > USA). With that in mind, let me propose that we schedule an informal meetup > in Mountain View, CA at Red Rock cafe, on castro street: > http://maps.google.com/maps?hl=en&client=firefox-a&rls=com.ubuntu:en-US:unofficial&hs=Eul&um=1&ie=UTF-8&q=red+rock,+94040&fb=1&cid=0,0,4140843673288073926&sa=X&oi=local_result&resnum=1&ct=image. > If you live halfway across the world and aren't planning travel out here > this month, don't worry -- I'm sure there will be other opportunities. > > We should probably set up a wiki for this sort of thing, but for this > meeting I'm happy to keep track of logistics via emails to this thread. For > now, I'd just like to know everyone's availability between the dates of > 10/23 and 10/31 at 7pm. > > Cheers, > > Michael Carter >
Re: [whatwg] Using as a source for canvas.drawImage
Nice feature! That will be quite useful. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ On Mon, Aug 18, 2008 at 2:45 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote: > Thanks to Anne for pointing this out... > > We've implemented using elements as an image source in > canvas.drawImage: > https://bugzilla.mozilla.org/show_bug.cgi?id=448674 > The extension is very obvious. Unlike animated images, which always draw > the first or poster frame, we draw the current frame of the video. This lets > you do things like make a thumbnail timeline. > > It'd be nice to have this in the spec. > > Rob > -- > "He was pierced for our transgressions, he was crushed for our iniquities; > the punishment that brought us peace was upon him, and by his wounds we are > healed. We all, like sheep, have gone astray, each of us has turned to his > own way; and the LORD has laid on him the iniquity of us all." [Isaiah > 53:5-6] >
Re: [whatwg] Video : Slow motion, fast forward effects
Hello, On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote: > Dave Singer wrote: > >> At 20:10 +1200 7/08/08, Chris Double wrote: >> >>> On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: >>> >>>> On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote: >>>> >>>>> >>>>> On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: >>>>> > playbackRate is the right way to do it, but maybe Firefox doesn't >>>>> yet >>>>> > support it. >>>>> >>>>> So can I assume HTML5 spec also allow playbackRate to be negative >>>>> value. >>>>> ie to support go backward at various speed >>>>> >>>> >>>> Yes. >>>> >>> >>> Would you expect the audio to be played backwards too? >>> >> >> I think that's extra credit and optional. As you say, even with audio >> coded in independent frames you have to flip the samples, which is a pain. >> For audio with forward dependencies, correct decoding means decoding >> forwards and then flipping whole chunks of timeline (though AAC doesn't >> suffer too badly if you don't do this, by the way). >> > > Honestly, this seems useless enough that the spec should just say that when > playback is less than 0 sound should be turned off. I'd hate to see > engineers working on this just because "the spec says it should work that > way". > I don't think turning sound off is a good idea. This feature would be used to implement "scrubing". Like what you see in Non-Linear Editors... for making movies, etc. (I.e., grabbing the "position handle" of the player, and moving it forwards and backwards through the video, and varying speeds, to find what you are looking for.) In those types of applications, the audio is on. And it is important for usability, for the video editor to hear the sound. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/
Re: [whatwg] Removing @rev
Hello, On Thu, May 15, 2008 at 6:05 AM, Nicholas Shanks <[EMAIL PROTECTED]> wrote: > On 14 May 2008, at 12:11 AM, Ian Hickson wrote: > > On Tue, 13 May 2008, Křištof Želechovski wrote: >> >>> >>> Removing @rev is harmful for Lynx because that is how it decides who the >>> author is. >>> >> > Removing rev="" from the spec doesn't preclude Lynx still supporting it >> for legacy documents, and for new documents, rel=author is preferred and >> is trivially supportable given support for rev=made, so I don't think >> this is a particularly convincing argument. >> > > For what it's worth, I always press 'c' before going hunting for a contact > address. It usually doesn't work, but that's life I guess. > > Ian: would it be too much to have the spec say that @rev is valid if and > only if its value is "made" or "owner"? > That way I can continue supporting older versions of lynx until people have > updated to a version supporting rel=author > > I generally prefer lynx over links, w3m and such when I'm ssh'd into > another machine, so I don't know much about them, but if they also support > @rev then that would be more reason to keep it in with these fixed values. > I thought the "rev" attribute was being added back? (Someone... I can't remember who... came on the Microformats mailing list, a while ago, and said something to that effect.) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/
Re: [whatwg]
Hello,
On Wed, Apr 30, 2008 at 12:19 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Apr 29, 2008, at 11:54 PM, Charles Iliya Krempeaux wrote:
>
[...]
>
> In practice, these things usually do not matter when using an icon in the
> user interface. But the sizes available do matter. I would not want to
> download a 512x512 icon for use as an iPhone homescreen icon (it's not
> anywhere near the right size) but it is irrelevant whether the compression
> is lossy or how colors are represented. I would prefer a multisize icon with
> a wide size range for Mac OS X or Windows Vista but not for Windows XP or
> most mobile platforms.
True... for an iPhone that might be the case. Or even Mac OS X or Windows
Vista. But it might become important in usages of this metadata beyond just
icons.
For example, consider a photo blogging example...
(The bottom if the original image. The 2 640x480 onews are scaled
version... one color and one grayscale. And the top one is a thumbnail.)
>
>
> >
> > If we have this new attribute(s) available on the element, then
> > it is very likely going to be used for other things besides just icons.
> >
> > You could use width and height for videos too. What if video wants to
> > be able to "declare" that the video has "closed captioning" embedded or
> > not?! Or what language the video file has audio for?! ("hreflang" would
> > almost work for that... if it let you specify more than one language.)
> > Or`what "ratings" that version of the video is?!
> >
> >
> > What I was getting at with this suggestion is that if we start adding
> > the ability to specify all sorts of metadata about what's being linked to
> > and go along the path of #1, then we likely need to create a kind of complex
> > language to describe this. (Something approaching the complexity of CSS.)
> > And perhaps that's complicating the element too much.
> >
> > Maybe it's simpler to (do #2 and) just create a for each thing.
> >
>
> I'm not sure I understand this. Your proposal amounts to adding two new
> attributes to the element, "width" and "height" (and possibly
> specifying a link of the same type to the same item multiple times). My
> proposal involves a single new attribute on , with essentially the
> same information conveyed in a more compact way. Why does my proposal lead
> to a CSS-like general-purpose metadata language, but yours does not?
>
It leads to a CSS-like language only if we start adding more metadata in
there besides just the width and height.
For example, this...
... could become...
The "metadata" attribute is where you start to get a CSS-like language.
(Which seems to complicate the element.)
See ya
--
Charles Iliya Krempeaux, B.Sc.
http://ChangeLog.ca/
Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [whatwg]
Hello,
On Tue, Apr 29, 2008 at 11:24 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Apr 29, 2008, at 10:24 PM, Charles Iliya Krempeaux wrote:
>
> Hello,
>
> On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> >
> > On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote:
> >
>
> [...]
>
>
> >
> >
> > > href="whatwg.ico">
> >
> >
> >
> >
>
> Couldn't this also be done as...
>
>
>
> href="whatwg.ico">
> href="whatwg.ico">
>
> href="whatwg.icns">
> href="whatwg.icns">
> href="whatwg.icns">
> href="whatwg.icns">
> href="whatwg.icns">
> href="whatwg.icns">
>
> href="whatwg.png">
>
> Basically 'ing to the same "icon" more that once for each size it is
> "good" for.
>
>
> a) This may not be obvious to authors.
> b) It's more boilerplate for the author.
> c) It's more work for the UA to process (if it prefers a multisize icon it
> has to look for all icon type links and merge references to the same file).
> d) It does not distinguish between scalable icon and icon where the author
> did not specify a size (which would be all icons present in existing link
> attributes).
>
> I fail to see the advantages of this approach.
>
I don't really prefer one to the other, just considering the possibilities
we have at hand.
My current thinking is that you can go one of 2 ways.
#1: Pack everything into in element. (I.e., what you were
suggesting.) Or...
#2: Expand everything into its own element. (I.e., what I was
suggesting.)
My thinking is that... we're now considering adding width and height info
(via one or two new attributes)... but I could see this progressing to
adding other new attributes too (... perhaps in HTML5... or perhaps in
version of HTML after that).
For example... if we have width and height now... well why not info about
the number of bits used for the colors?! Why not info about if the coloring
is palleted or not?! Or if the image format uses lossless compression or
lossy compression?! Or the size of the file?! Etc
If we have this new attribute(s) available on the element, then it is
very likely going to be used for other things besides just icons.
You could use width and height for videos too. What if video wants to be
able to "declare" that the video has "closed captioning" embedded or not?!
Or what language the video file has audio for?! ("hreflang" would almost
work for that... if it let you specify more than one language.) Or`what
"ratings" that version of the video is?!
What I was getting at with this suggestion is that if we start adding the
ability to specify all sorts of metadata about what's being linked to and go
along the path of #1, then we likely need to create a kind of complex
language to describe this. (Something approaching the complexity of CSS.)
And perhaps that's complicating the element too much.
Maybe it's simpler to (do #2 and) just create a for each thing.
See ya
--
Charles Iliya Krempeaux, B.Sc.
http://ChangeLog.ca/
Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [whatwg]
Sorry to reply to my own reply. For vector formats, that can be scaled to any size, it might be a good idea to be able to specify the aspect ratio somehow. For example, if the aspect ratio of one vector format icon is 4:3 and the other 16:9, then it would be a "good" idea to be able to specify those somehow. So possibly something like... (Note, I used the N* format to specify that the width and height are ratios rather than pixel measurements. For some reason I remember seeing these used on elements before... although I couldn't find anything like it in doing a quick look over the the HTML5 spec. So maybe those didn't come from the spec.) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/ On Tue, Apr 29, 2008 at 10:24 PM, Charles Iliya Krempeaux < [EMAIL PROTECTED]> wrote: > Hello, > > On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > > > > On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: > > > > [...] > > > > > > > > > href="whatwg.ico"> > > > > > > > > > > Couldn't this also be done as... > > > > href="whatwg.ico"> > href="whatwg.ico"> > > href="whatwg.icns"> > href="whatwg.icns"> > href="whatwg.icns"> > href="whatwg.icns"> > href="whatwg.icns"> > href="whatwg.icns"> > > href="whatwg.png"> > > Basically 'ing to the same "icon" more that once for each size it is > "good" for. > > > See ya > > -- > Charles Iliya Krempeaux, B.Sc. > http://ChangeLog.ca/ > > > Vlog Razor... Vlogging News... http://vlograzor.com/ >
Re: [whatwg]
Hello, On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: > [...] > > > href="whatwg.ico"> > > > > Couldn't this also be done as... Basically 'ing to the same "icon" more that once for each size it is "good" for. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [whatwg] lede element
Hello, On 10/2/07, Devi Web Development <[EMAIL PROTECTED]> wrote: > > The proposal was purely for the sake of semantics. A > styled appropiately via CSS works and looks fine. The element would > obviously add no functionality. However, I though that this element would > add more semantic richness and would be useful to news aggregators in > particular as an alternative to using the first sentence (Google), the first > paragraph (Yahoo) or the meta description(bbc). On the Microformats mailing list, there was discussions about summaries at one time. (I think it was when hAtom was being discussed.) At one time there was a proposal to use class-summary for marking the summary of an article. You could even use multiple instances of class-summary... and have the summary be a concatenation of all there (with spaces or something in between... maybe with ellipses too). For example... Lorem ipsum dolor sit amet, consectetur adipisicing elit. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Notice that 3 things in there are marked with class-summary. So then the summary might be something like... Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ... Excepteur sint occaecat Or... Lorem ipsum dolor sit amet, consectetur adipisicing elit. ... Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ... Excepteur sint occaecat Depending on how you want to render it. See ya -- Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/> Vlog Razor... Vlogging News http://vlograzor.com/
Re: [whatwg] The issue of interoperability of the element
Hello Jerason, From a technical point-of-view, you make a very good argument. However, I think it is inappropriate for the HTML spec to (directly or indirectly) mandate people pay to implement it. As you point out, H.263 is encumbered by patents and has licensing costs associates with it. Costs that me, you, tool creators, and users will have to pay, either directly or in-directly This just makes things more expensive for everyone since we are essentially being "taxed". And it's ridiculous to just accept this tax when there's no reason we have to. See ya -- Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/> All the Vlogging News on One Page http://vlograzor.com/ On 6/26/07, Jerason Banes <[EMAIL PROTECTED]> wrote: > I believe an aim of whatwg is a viable implementable standard that > reflects the realities of the web while encouraging innovation. MPEG4 > is part of the web (a growing part too). > If I may, I'd like to echo Timeless's point here. I've been watching this thread with great interest and believe I understand both sides of the issue. Theora is appealing because it provides a Free as in no-cost to implement and Free as in no-encumbrances solution. However, it also provides a solution that nobody uses today. Perhaps even worse, there doesn't seem to be a lot of interest in adopting Theora in the future. And can you blame web users? Theora provides a solution that's high bandwidth and low quality. A very unappealing prospect for the bandwidth-constrained environment of the web.Thus more competitive solutions like MPEG4, WMV, RealPlayer, and Quicktime have been dominating the web. The most popular form of video streaming at the moment is actually the H.263 codec through Flash; a non-free codec which is running on a platform that can only roughly be considered a "standard". If and when the Dirac codec is completed, there will be a viable alternative to the non-free video codec problem that might justify the risk/reward equation for support. Until then, however, we're going to need to look at supporting the existing infrastructure. That infrastructure is based on the following options: VP6 Windows Media Video MPEG4 RealVideo 30/40 H.263 Quicktime SorensonOut of those solutions, VP6, WMV, Sorenson, and RealVideo can immediately be discarded for their lack of standardization. That leaves H.263 and MPEG4 as the only viable options. H.263 is not a bad choice, IMHO. It's well supported by nearly every major video player, has a variety of library implementations available, is in widespread usage, and has a good tradeoff between bandwidth and quality. It is also a standard under the ITU-T. But what about MPEG4? Specifying MPEG4 has a lot of appeal for both its excellent encoding performance and its single point to obtain licensing and indemnity from. Furthermore, MPEG4 has its own container format and low-bandwidth audio encoding scheme. (AAC is a sight better than having to dictate ADPMC sound.) MPEG4 is also widely supported by media players, though not quite as well as H.263. The MPEG Group also offers low-cost (i.e. "free") licensing to anyone shipping less than 50,000 units a year, which means that it would be feasible for upstart browsers to support the standard. That being said, I think I prefer the H.263 standard as a video baseline for a few reasons: It presents several licensing options. The implementer can chose to get indemnity via an available license like MPEG4-Simple (which will play H.263), choose to try and deal with individual patent holders, or simply attempt to ignore the issue. (The last case is particularly appealing in countries that don't recognize the patents related to streaming video technologies.) It's amazingly well supported both in hardware and software. Future mobile devices should have no trouble adding support for H.263. It's already the most popular codec on the web today. While Real has "retired" their H.263-based codecs, it still lives on in Adobe FLV files. Java decoders are available for creating "shunts" for browsers that don't currently support the "" tag. That leaves me with two (point 5) questions: Would this place too much of a burden on browsers like Mozilla and Opera? Could plugins to local OS codecs or media players slide around the licensing issues? Is there a good choice for container format that wouldn't additionally burden the implementors? Thanks, Jerason
Re: [whatwg] The issue of interoperability of the element
Hello, (Sorry if this gets posted twice.) On 6/25/07, timeless <[EMAIL PROTECTED]> wrote: On 6/25/07, Spartanicus <[EMAIL PROTECTED]> wrote: > My main worry relates to the usability and accessibility of future audio > and video web content. Content including the wrapping should be free, you don't quite mean that. if a content producer wants to make pay content, it should be free to do that too, no? There are huge industries which drive a large portion of the industrialized world based on a premise like this. I believe he means "free" as in "freedom" or "liberty". And not "free" as in "free of charge" or "gratis" as you are using the word. The words look and are spelled the same but they have very very different meanings. Anything that is patent encumbered is NOT free as in "freedom" or "liberty". But if you can get people to voluntarily pay for it, there's nothing that goes against the concept of "freedom" to do that. See ya -- Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/> All the Vlogging News on One Page http://vlograzor.com/
Re: [whatwg] The issue of interoperability of the element
Hello, On 6/25/07, Maik Merten <[EMAIL PROTECTED]> wrote: [...] This assistance could be a "video component download service" that comes with Safari or QuickTime or some web portal (similar to http://www.apple.com/quicktime/resources/components.html - but with guidance what component is currently of interest). [...] Unsuspending that program or having talks with (in this case) xiph.org (they already have a working QT component) outside of that program sounds like a good way to strengthen the interoperability of Safari with Opera and Mozilla. I heard that xiph.org tried to participate in that QuickTime download program in the past but that this more or less stalled on Apple's side (I only heard one side of the story, though). Here's the link if anyone is curious... http://xiph.org/quicktime/ See ya -- Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/> All the Vlogging News on One Page http://vlograzor.com/
Re: [whatwg] The issue of interoperability of the element
Hello, On 6/25/07, Maik Merten <[EMAIL PROTECTED]> wrote: [...] If Safari is encountering "application/ogg" and it can't decode that stuff then redirect (after asking of course) the user to a fitting QuickTime component download page on e.g. xiph.org or even automate the process of installing a fitting 3rd-party component after the user acknowledged the process. Just an FYI There's plans to register the "video/ogg" MIME type, and use for Ogg based video. See ya -- Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/> All the Vlogging News on One Page http://vlograzor.com/
[whatwg] as thumbnails
Hello, I'd like to suggest the addition of another attribute to . This would be useful in cases where the element is used as a thumbnail. The new attribute is like the "cite" attribute on the element. I suggest we add an optional "cite" attribute to the element too, for when an element is used as a thumbnail. So for example... http://example.com/video"; > The rational is the be able to specify the source from which the thumbnail was made. (To be able to specify the source image or video from which the thumbnail was created.) And to be able to conceptual link together loosely coupled thumbnails together. (To be able to say... all these thumbnails are from the same source.) Use agents could let users get to the URL in the "cite" attribute of the element by right clicking on the thumbnail, or something like that. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] [WF2] Clear On Focus attribute
Hello, On 5/23/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On May 23, 2007, at 10:02 AM, Charles Iliya Krempeaux wrote: > > So... perhaps we can come up with a way for them to get this effect, > while preserving semantics. > > Maybe a new attribute? "innerlabel" maybe... or something like that. > > So, maybe something like > > > > (And this would have the effect described in the original post. I.e., > a text input box with "search in vancouver..." inside of it. When the > use clicks in the text input box, that text disappears.) Did you see the proposal to use WebKit's "placeholder" attribute for this purpose? It already works the way you suggest. Guess that's another reason to have an attribute like that in HTML5 :-) -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] [WF2] Clear On Focus attribute
Hello Alexey, On 5/23/07, Alexey Feldgendler <[EMAIL PROTECTED]> wrote: On Wed, 23 May 2007 02:31:38 +0200, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: > You need a label for the field... but don't want to put one beside it. > So the label goes inside the field... until you click on it. (At > which point the label disappears.) The field's value shouldn't be abused to achieve this effect because the label is not a value. Stylesheets should be used to get a semantically appropriate piece of information, such as the field's title, to display in the box when the field is empty and has no focus. It's true that web developers probably should not be doing this. (Since it messes up semantics.) But they are. So... perhaps we can come up with a way for them to get this effect, while preserving semantics. Maybe a new attribute? "innerlabel" maybe... or something like that. So, maybe something like (And this would have the effect described in the original post. I.e., a text input box with "search in vancouver..." inside of it. When the use clicks in the text input box, that text disappears.) (Although maybe a new "innerlabel" attribute is the wrong way to do this. Perhaps a combination of the element and the element can be used for this... BUT where CSS can be extended somehow to put the text of the into the text box.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] [WF2] Clear On Focus attribute
Hello, On 5/22/07, Matthew Paul Thomas <[EMAIL PROTECTED]> wrote: On May 22, 2007, at 3:35 AM, Stijn Peeters wrote: > > It is becoming increasingly common to have an input field clear its > value when it is first focused. Though in a lot of cases this is > actually wrong usage of the value="" attribute for something which > should actually be done with (such as a search box filled with > "Enter search query here" that becomes empty when you first click it), Indeed. > it is possible to come up with legitimate use cases; the first thing > that comes to mind are input fields with placeholder or default values > that may need to be changed. This goes well together with WF2's new > abilities for prefilling forms. > > It makes sense to clear these values when the field is focused, as the > user will probably want to insert a new value rather than edit the > value that is currently in it. > ... I don't understand. What use is a default value if you can't edit it? Why not make the field empty to begin with? It's a Usability issue mixed with a Graphical design / aesthetics issue., You need a label for the field... but don't want to put one beside it. So the label goes inside the field... until you click on it. (At which point the label disappears.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Predefined classes are gone
Hello Adrienne,
I'm not sure how good or bad IE is in general at this stuff.
But I know escaping the ":" works in IE (for CSS)... because I did it
before. (Works in Firefox too of course.)
See ya
On 5/17/07, Adrienne Travis <[EMAIL PROTECTED]> wrote:
Charles,
I went and looked, and per the spec you're right (any Unicode
character, escaped, is valid) -- BUT, how do parsers/UAs treat them? I
know IE has trouble with certain escaped characters, for instance. Not
that i'm interested in coddling IE -- but it'd be good to make sure
that more forward-thinking UAs aren't making the same mistake.
Adrienne
On 5/17/07, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:
> Hello Adrienne,
>
> On 5/17/07, Adrienne Travis <[EMAIL PROTECTED]> wrote:
>
> [...]
>
>
> > But unfortunately, that
> > totally breaks backwards-compatibility if not done very carefully. (If
> > i declare class="dc:author" , i CAN'T address that in my stylesheet.
>
> I believe you can style the class name "dc:author" with CSS code like
the
> following...
>
> dc\:author {
> /* Your style here */
> }
>
> (Note the backslash in there.)
>
> So, no need for doing stuff with dashes.
>
>
> > If the namespacing was handled with dashes, like class="dc-author",
> > that would work, though.)
>
> [...]
>
>
> See ya
>
>
> --
> Charles Iliya Krempeaux, B.Sc.
>
> charles @ reptile.ca
> supercanadian @ gmail.com
>
> developer weblog: http://ChangeLog.ca/
>
>
--
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
Re: [whatwg] Predefined classes are gone
Hello Adrienne,
On 5/17/07, Adrienne Travis <[EMAIL PROTECTED]> wrote:
[...]
But unfortunately, that
totally breaks backwards-compatibility if not done very carefully. (If
i declare class="dc:author" , i CAN'T address that in my stylesheet.
I believe you can style the class name "dc:author" with CSS code like the
following...
dc\:author {
/* Your style here */
}
(Note the backslash in there.)
So, no need for doing stuff with dashes.
If the namespacing was handled with dashes, like class="dc-author",
that would work, though.)
[...]
See ya
--
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
Re: [whatwg] toDataURL() and unsupported formats
Hey, On 5/8/07, Ian Hickson <[EMAIL PROTECTED]> wrote: On Sat, 20 May 2006, Aankhen wrote: > > On a perhaps related note, is there a reason for calling it toDataURL() > instead of toDataURI()? Basically for consistency with the rest of the platform (starting with CSS's url() form). I can't keep track of what URIs are called these days. First it was URLs, then URIs, then there were URNs and shortly after that the correct term was URLs again, then URL was obsolete altogether and URI was the right term; then we had IDN and IRIs, and more recently we've started having XRIs... Whatever. Authors don't need this. "URL" is fine. I've hear "normal people" saying "URL" too. (It seems to have entered "common language".) But I've never heard a "normal person" saying any of the others -- saying "URI", "URN", "IDN", "IRI", or "XRI". See ya Whether the answer is yes or no, it might be a good idea to tweak that > section slightly to be more consistent, since it seems to use URI and > URL interchangably. Fixed, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Sandboxing ideas
Hello Ian, On 5/7/07, Ian Hickson <[EMAIL PROTECTED]> wrote: [...] What do people think? (Sorry if you get a double post... my preview reply got thrown into the moderation queue, because it was too long. But anyways) I'd also suggest that the be able to "stretch" somehow (at the web developer's request... through an attribute or something). For example, if I put a blog post comment into an (for security reasons), then, because of the style of the website... I'd want the width of that to be fixed... but, I'd want the height of the to "stretch" as much as it needs to, so that a scrollbar does NOT appear on the See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Target Attribute Values
Hello, Here's one use case In the online advertising business, ads are usually put in s for security reasons. (So the ad can't tell what page it's on... get user cookies from that domain... etc.) So... if you didn't use a "_blank" for the target, the landing page for the ad would open up in the tiny (instead of a new window). See ya On 4/26/07, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Hi, This is regarding the valid browsing context names, used for the target attribute [1]. Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? _new is also not specced, yet it is widely used and treated as a magic value like _blank in Firefox. Maybe it should be specced the same as _blank. However, IE, Opera and Safari didn't appear to treat it as such, so maybe it's not needed. http://www.whatwg.org/specs/web-apps/current-work/#valid8 -- Lachlan Hunt http://lachy.id.au/ -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] sarcasm
Hello, On 4/24/07, Elliotte Harold <[EMAIL PROTECTED]> wrote: Alexey Feldgendler wrote: > In Western typography, there is already a tradition to mark up irony > with quotation marks: > > Yeah, George W. Bush has been such a "great" president. There's an even stronger tradition to mark quotes with quotation marks, and yet we have the q element. It would be interesting if such a new element would provide a method of specifying the real meaning. For example... That's huge! See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] sarcasm
Hello, On 4/24/07, Arne Johannessen <[EMAIL PROTECTED]> wrote: Elliotte Harold wrote: > It occurs to me that one of the most frequently used nits of pseudo- > markup is to indicate sarcasm. I do like the idea of formalising that -- but considering the way the sarcasm element occasionally is used in emails, we may find it necessary to make its start tag optional... ;-) Yeah... like the winking smiley, the lone "" seems to be used more like a punctuation mark (than markup) at times. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] sarcasm
Hello, On 4/24/07, Elliotte Harold <[EMAIL PROTECTED]> wrote: It occurs to me that one of the most frequently used nits of pseudo-markup is to indicate sarcasm. For example, Yeah, George W. Bush has been such a great president. Should we perhaps formalize this? Is there any benefit to be achieved by adding an explicit sarcasm element to HTML? An interesting proposal. Some other things to consider is some of the other ways people mark up sarcasm. Some people mark it with a winking smiley. As in... ;-) Or... ;) Although, this tends to be when a person is being sarcastic to be funny or to tease someone. I don't believe I've ever seen (or used myself) the winking smiley when I'm being sarcastic AND I'm trying to be mean to the person, to in a heated argument. (I.e., using sarcasm to "make a point".) Also... I've heard that Ethiopian Semitic languages and French actually has a punctuation mark for sarcasm. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
Hello, This reminds me of when Lucas Gonze was arguing that MIME types (and Content Types) were dead. http://tech.groups.yahoo.com/group/videoblogging/message/48276 See ya On 4/12/07, Kevin Marks <[EMAIL PROTECTED]> wrote: On 4/11/07, Dave Singer <[EMAIL PROTECTED]> wrote: > > We had to settle on one type that was valid for all files, to deal > with the (common) case where the server was not willing to do > introspection to find the correct type. We decided that "audio/" > promises that there isn't video, whereas "video/" indicates that > there may be. It's not optimal, agreed. I agree that video/xxx and audio/xxx are useful distinctions. Another point is that as IE ignores MIME types in favour of extensions, in practice we end up with multiple extensionss pointing to the same filetype, to give a cue for differentiation: .wmv vs .wma .m4v vs .m4a (also .m4p for DRM'd and .m4b for audiobooks, no?) That these distinctions keep being made, despite neutral formats with extensions like .mov, .avi, .mp4 and .ogg implies that there is some utility there. -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Web Archives
Hello, Do any of the existing web archive formats out there store the "ETag" or "Last-Modified" of the resources it is archiving? See ya On 4/11/07, Tyler Keating <[EMAIL PROTECTED]> wrote: Hi, I apologize if I've missed this in the specification or mailing archives, but I have a suggestion related to standardizing web "archives" in HTML5. Currently, I know that Firefox uses Mozilla Archive Format (.maf), Internet Explorer and Opera use MIME HTML (.mht) and Safari uses its own format (.webarchive) for saving a web page and all of its resources into a single file. So clearly a standard would be beneficial in ensuring "archive" compatibility between browsers and I think it's suitable for that standard to reside in HTML5. I don't believe this would be very difficult to standardize and the solution may be nothing more than a collection of random files wrapped into a ZIP compressed archive with a unique extension similar to a JAR or ODF file. The unique extension would be recognized by browsers, email clients and editors, which could then extract and display the root file directly (ex. index.html). The root file would obviously contain relative URIs to any other HTML, JavaScript, CSS, images and other files in the archive so the internal structure may not be important and the browser would not need any new rules to interpret individual files once it has uncompressed the archive into memory. This would facilitate passing HTML based documents around that could be viewed with any browser, yet appear as a small single file. -Tyler -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
Hello, On 4/9/07, Dave Singer <[EMAIL PROTECTED]> wrote: WARNING: I have CC'd the co-authors of the RFC, as I think they might like to see the discussion, comment on my answers, and possibly correct me. I also have a question whether there is a typo in the RFC... * * * * * Henry these are all great questions. Let me see how many I can answer. Overall, the RFC was struggling with the issue that there is no 'uniform' naming of codecs; the namespace for codecs is dependent on the container format, so products that do container conversion have to have tables of code matches. ugh. That's why the RFC is as it is. The RFC suggests that updated information would be done with RFCs, which is a little heavy. The RFC as written formally applies to 3GPP files and 3GPP2 files, but the definitions are applicable for all ISO-family files. As you'll see below, 3GPP has also defined it for avc1 in MP4-family containers, but no spec. or registration authority provides a pointer. We might want to ask IANA whether we could add something to the MIME registry. At 11:37 +0300 8/04/07, Henri Sivonen wrote: * Theora video and Vorbis audio in Ogg container. (application/ogg; .ogg) * Dirac video and Vorbis audio in Ogg container. (application/ogg; .ogg) * Theora video and Vorbis audio in Matroska container. (video/x-matroska; .mkv) * Dirac video and Vorbis audio in Matroska container. (video/x-matroska; .mkv) My understanding is that the Ogg container is 'specific' to these codecs, and therefore the codecs parameter is not needed. But I am not an Ogg or Matroska expert; perhaps they could chime in? No. The containers are independent of the codecs put inside. However, whether software, that supports Ogg or Matroska containers will actually be able to "play" other codecs is another issue altogether. [...] See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] [rest-discuss] Atom, 'process-this'-POST and rockets
Hello Elliotte, On 12/3/06, Elliotte Harold <[EMAIL PROTECTED]> wrote: Josh Sled wrote: > Aye. As much as people like to talk about the 4 Holy Operations, it > pretty clear that only 2 are in practical use, and I don't think that is > because HTML Forms don't allow for PUT and DELETE. Why not? That seems exactly why to me. I agree. If PUT and DELETE were available with HTML forms I'd be using them. (I actually tried it a long time ago after reading the HTTP spec.) I even know a few artists (who markup HTML) that, once learning a little more about HTTP and the other HTTP methods, actually tried using them since it made more semantic sense. (Although they didn't use the word "semantic" when asking me why it wasn't working. But... the point is that I even know "artist types" that would use them if they could.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Provding Better Tools
Hello Lachlan, On 12/2/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Lachlan Hunt wrote: > Work is being done on such tools now. A few of us have begun writing a > parser in Python, which will be either public domain (preferably) or > under a free software licence. We've just set up a project for it in Google Code, and decided to put it under the MIT licence. http://code.google.com/p/html5lib/ http://wiki.whatwg.org/wiki/HTML5Lib Do you know if anyone is creating anything for PHP? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] 9.1.2.1: trailing slash and atheism
Hello Ian, On 12/1/06, Ian Hickson <[EMAIL PROTECTED]> wrote: On Fri, 1 Dec 2006, Elliotte Harold wrote: > > 9.1.2.1 states: > > Then, if the element is one of the void elements, then there may be a single > U+002F SOLIDUS character. This character has no effect [...] > > The second sentence is false [...] I suggest rewriting as follows: > > This character has no effect when the document is parsed by an HTML5 parser. That's redundant. Parsing a document using this syntax with anything other than an HTML5 parser would be non-conforming. > However, if the document when parsed by an XML parser, the trailing > slash converts the tag into an empty-element tag, and thereby makes an > otherwise malformed element well-formed. This section has nothing to do with XML. If the document was parsed by an XML parser, then there are much bigger problems afoot, such as MIME type mislabelling, or a faulty UA. Sometimes web developers parse (non-XML) HTML with an XML parser because it's the tool they have on hand. Consider a PHP developer trying to analyse an HTML page. If a PHP developer wants to analyse an HTML page; that developer may try to use SimpleXML <http://php.net/simplexml> because that's what they have on hand and know how to use. There's no SimpleHTML available in PHP. And while none of this is certainly our fault. This is a situation some web developers are going to run into. (What else are they going to use?) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] xml:lang and xmlns in HTML
Hello Ian, On 12/1/06, Ian Hickson <[EMAIL PROTECTED]> wrote: On Fri, 1 Dec 2006, Michel Fortin wrote: > > I wonder if xml:lang and xmlns couldn't be made legal in HTML. xml:lang > would simply become conformant in HTML as a synonym for the lang > attribute, it's already in the spec that it should get the correct > treatment anyway. Except that wouldn't be backwards compatible since xml:lang="" isn't treated as a language attribute in legacy UAs. > This would make it possible to have documents conformant with both > syntaxes at the same time. I thought XHTML-sent-as-text/html had explained in painful detail why that's not a desirable end goal. Why would we want this? Do you have some links to that discussion. I think I may have missed it. (I know I probably don't qualify as a "typical" web developer, but... I've actually been writing XHTML and returning it as "text/html".) See ya This could also help reinforce the idea that it's the media type that > differentiate HTML from XHTML. It'd make many valid XHTML1 documents out > there conformant with HTML5 with a mere modification to the doctype. Not if they use things like or the empty element syntax on non-void elements, or any number of other XMLisms. > What do you think? I don't think it's a goal for the two serialisations to have a common subset. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello Gervase, On 11/15/06, Gervase Markham <[EMAIL PROTECTED]> wrote: Michel Fortin wrote: > I'm beginning to think that the link "fingerprint" method is best > solution because the hash is more portable as part of the URL. I could > for instance copy a fingerprinted URL right into this email: > > http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967 Indeed, that's one of the major use cases. > and a knowledgeable browser receiving this URL would know how to check > the validity of the received document. The two concerns I have with it > is that it somewhat distorts the concept of a fragment identifier, It does a bit; but the fragment identifier is unused for binary downloads, so there's not much risk of a clash. Just an FYI. I've been promoting the use of fragments for (binary) video file. (Not here... but privately and on one public mailing list.) For example... http://example.com/video.mpeg#smtpe(01:20:39:15) Also, I've suggested (privately and on one public mailing list) the use of fragments on video files for "pointing to" clips. (I.e., "pointing to" intervals of the video.) For example... http://example.com/video.mpeg#smtpe(01:20:39:15-01:28:14:50) (Note that there are 2 SMTPE time codes there separated with a hypen. So it would be the clip, with in the video, from "01:20:39:15" to "01:28:14:50".) (This notation was inspired by the "xpointer" fragments.) See ya Also, "!" is currently not legal in HTML ids, AIUI. > and > it's generally going to be lost if there is any redirection (although a > browser that knows about fingerprints could keep them across redirections). Indeed. In fact, it would be a security flaw to update the identifier on redirect. Gerv -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Allow omitting ="" for attributes?
Hel On 11/15/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Charles Iliya Krempeaux wrote: > On 11/15/06, Simon Pieters <[EMAIL PROTECTED]> wrote: >> From: "Charles Iliya Krempeaux" <[EMAIL PROTECTED]> >> >What's the "whattf"? >> >> Web Hypertext Application Technology Task Force. > > Do you have any more details about it? (Or is it a secret?) > > Is it related to the whatwg? It's just an alternative name for the WHATWG, which some people thought had a better acronym, presumably because it looks like an abbreviation of "What The F...?" LOL -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Allow omitting ="" for attributes?
Hello Simon On 11/15/06, Simon Pieters <[EMAIL PROTECTED]> wrote: Hi, From: "Charles Iliya Krempeaux" <[EMAIL PROTECTED]> >What's the "whattf"? Web Hypertext Application Technology Task Force. :-) Do you have any more details about it? (Or is it a secret?) Is it related to the whatwg? (This is the first I've heard about it... so I'm just curious.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Allow omitting ="" for attributes?
Hello, On 11/15/06, Simon Pieters <[EMAIL PROTECTED]> wrote: Hi, From: "Rohan Prabhu" <[EMAIL PROTECTED]> >In that case, we need to have a provision in either DTD or XML-Schema >to allow empty attributes and take default values instead, as this >proposal clearly violates XML Syntax rules. The proposal was about HTML5, which is not XML (nor SGML). HTML5 has its own syntax rules. http://whatwg.org/specs/web-apps/current-work/#syntax >And we need to have a DTD, Schema or a validation entity somewhere to >materialize the WHATWG's specifications. Schemas won't be normative, but work in this area has been started: http://syntax.whattf.org/ What's the "whattf"? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello, On 11/14/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello, On 11/14/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: > > Hello, > > On 11/1/06, Charles Iliya Krempeaux < [EMAIL PROTECTED]> wrote: > > > > Hello Christoph, > > > > On 11/1/06, Christoph Päper < [EMAIL PROTECTED]> wrote: > > > > > > *Henri Sivonen*, 2006-10-29: > > > > > > >> http://blog.fawny.org/2006/10/28/tbl-html/ > > > > > > > >> * HTML has samp, var, and kbd. I use all of them and I am > > > >> pretty much the only one who does. > > > > > > > > FWIW, I think and don't deserve to be in HTML and I > > > am > > > > not convinced that the use cases for could not be satisfied > > > > by . > > > > > > I consider > > > > > > > > > > > > > > Thinking about it some more, something like the element may be > useful as well for marking thumbnails. > > So, you might have something like this... > > http://example.com/video/123";> > http://example.com/video/123 "> > http://example.com/thumbnail/123"; /> > > > > (Although you'd probably want to add a "quotes:none;" to that > element, since some browsers wrap a with quotes.) > > One would know that the is from the video because the URL in > "cite" attribute (for the element) matches the URL in the "href" > attribute (of the element.) > Doing it this way (with the element instead of the element) would also allow you to take the thumbnail outside of the link. So, for example... http://example.com/video/123 "> http://example.com/thumbnail/123"; /> http://example.com/video/123";>[download] The "cite" attribute (of the element) and the "href" attribute (for the element) could still be matched up to find thumbnail, in this configuration too. (Sorry for replying to my own e-mail message again) If we still had the "urn" attribute on the element, we could use it to specify alternatives of the same video. So, for example... http://example.com/video/123/mpeg";> http://example.com/thumbnail/123"; /> http://example.com/video/123/mpeg";>[MPEG] http://example.com/video/123/mov ">[QuickTime] Just to say it explicitly, the "cite" attribute matches only one of those links. (It could be any of them. It doesn't matter.) Alternatively, I think it would probably be semantically OK if the urn was even put in there -- in the "cite" attribute. As in... http://example.com/thumbnail/123"; /> http://example.com/video/123/mpeg";>[MPEG] http://example.com/video/123/mov ">[QuickTime] (That way you don't have to play favorites.) Any chance we can get the "urn" attribute on the element back? :-) (And note... for those that think that "urn:uuid:0a8d2f83-d5d2-44e7-bde9-319aaadc219c" looks ugly. You do NOT have to use URN's that look like that. Another example of a URN is: "urn:ietf:rfc:3023".) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello, On 11/14/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello, On 11/1/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: > > Hello Christoph, > > On 11/1/06, Christoph Päper < [EMAIL PROTECTED]> wrote: > > > > *Henri Sivonen*, 2006-10-29: > > > > >> http://blog.fawny.org/2006/10/28/tbl-html/ > > > > > >> * HTML has samp, var, and kbd. I use all of them and I am > > >> pretty much the only one who does. > > > > > > FWIW, I think and don't deserve to be in HTML and I am > > > not convinced that the use cases for could not be satisfied > > > by . > > > > I consider > > > > > > Thinking about it some more, something like the element may be useful as well for marking thumbnails. So, you might have something like this... http://example.com/video/123";> http://example.com/video/123 "> http://example.com/thumbnail/123"; /> (Although you'd probably want to add a "quotes:none;" to that element, since some browsers wrap a with quotes.) One would know that the is from the video because the URL in "cite" attribute (for the element) matches the URL in the "href" attribute (of the element.) Doing it this way (with the element instead of the element) would also allow you to take the thumbnail outside of the link. So, for example... http://example.com/video/123 "> http://example.com/thumbnail/123"; /> http://example.com/video/123";>[download] The "cite" attribute (of the element) and the "href" attribute (for the element) could still be matched up to find thumbnail, in this configuration too. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello, On 11/1/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello Christoph, On 11/1/06, Christoph Päper <[EMAIL PROTECTED]> wrote: > > *Henri Sivonen*, 2006-10-29: > > >> http://blog.fawny.org/2006/10/28/tbl-html/ > > > >> * HTML has samp, var, and kbd. I use all of them and I am > >> pretty much the only one who does. > > > > FWIW, I think and don't deserve to be in HTML and I am > > not convinced that the use cases for could not be satisfied > > by . > > I consider > > Thinking about it some more, something like the element may be useful as well for marking thumbnails. So, you might have something like this... http://example.com/video/123";> http://example.com/video/123";> http://example.com/thumbnail/123"; /> (Although you'd probably want to add a "quotes:none;" to that element, since some browsers wrap a with quotes.) One would know that the is from the video because the URL in "cite" attribute (for the element) matches the URL in the "href" attribute (of the element.) Comments? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello,Also related are MAGNET-URIs... http://magnet-uri.sourceforge.net/See yaOn 11/7/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello,Also, something else to think about is that, under certain conditions, this info could potentially be passed along via HTTP headers.Maybe something like:HTTP/1.1 200 OKLink: < urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8=>; rel="hash"See yaOn 11/7/06, Charles Iliya Krempeaux < [EMAIL PROTECTED]> wrote:Hello,Here's something else related... http://microformats.org/wiki/hash-examplesSee ya On 11/7/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude < [EMAIL PROTECTED]> wrote: How about a hash attribute for all elements that link to external files (a, img, etc.)?It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a user-agent for automatic comparison with the linked file. I'd suggest a format where the hash algorithm is listed, followed by a forward slash and then the hash itselfExamples:hash="MD5/9e107d9d372bb6826bd81d3542a419d6"hash="SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12" hash="SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592"See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello,Also, something else to think about is that, under certain conditions, this info could potentially be passed along via HTTP headers.Maybe something like:HTTP/1.1 200 OKLink: < urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8=>; rel="hash"See yaOn 11/7/06, Charles Iliya Krempeaux < [EMAIL PROTECTED]> wrote:Hello,Here's something else related... http://microformats.org/wiki/hash-examplesSee ya On 11/7/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude < [EMAIL PROTECTED]> wrote: How about a hash attribute for all elements that link to external files (a, img, etc.)?It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a user-agent for automatic comparison with the linked file. I'd suggest a format where the hash algorithm is listed, followed by a forward slash and then the hash itselfExamples:hash="MD5/9e107d9d372bb6826bd81d3542a419d6"hash="SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12" hash="SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592"See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello,Here's something else related... http://microformats.org/wiki/hash-examplesSee yaOn 11/7/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude < [EMAIL PROTECTED]> wrote: How about a hash attribute for all elements that link to external files (a, img, etc.)?It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a user-agent for automatic comparison with the linked file. I'd suggest a format where the hash algorithm is listed, followed by a forward slash and then the hash itselfExamples:hash="MD5/9e107d9d372bb6826bd81d3542a419d6"hash="SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12" hash="SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592"See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude <[EMAIL PROTECTED]> wrote: How about a hash attribute for all elements that link to external files (a, img, etc.)?It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a user-agent for automatic comparison with the linked file. I'd suggest a format where the hash algorithm is listed, followed by a forward slash and then the hash itselfExamples:hash="MD5/9e107d9d372bb6826bd81d3542a419d6"hash="SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12" hash="SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592"See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] XMLHttpRequest connection limit
Hello,I think we're starting to see some of the limits of HTTP being hit.Personally, I'd like to a protocol which allows communication in both ways.HTTP 1.2? XMPP/Jabber? Something else? See yaOn 11/1/06, Ted Goddard <[EMAIL PROTECTED]> wrote: Ajax applications often make use of multiple concurrentHTTP requests; in particular Ajax Push (Comet/Reverse Ajax)makes use of two HTTP connections: one to block waiting formessages from the server, the other to send messages to the server.The problem is that the connection limit for many browsersis two connections per browser per server. SophisticatedAjax applications, on the other hand, need two connectionsper window (or tab) per server. This allows each window or tab to support two-way messaging with the server. Withoutit (and without the ability for the two client windowsto communicate and thereby share a single connection) thetwo available HTTP connections become consumed by the blocking message requests.I would like to propose that the HTTP connection limitbe standardized at two per user-initiated window. (Forinstance, Safari is not limited to two connections perbrowser.) This should be a relatively straightforward change in browser policy (browsers other than Safari,that is), but it is a significant enhancement forAjax applications.Ted.Ted Goddard, Ph.D. - Senior Software ArchitectICEsoft Technologies Inc Suite 300, 1717 10th St. NWCalgary, AB - Canada - T2M 4S2T 403 663-3322F 403 663-3320[EMAIL PROTECTED]http://www.icesoft.com -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello James,On 11/1/06, James Graham <[EMAIL PROTECTED]> wrote: Charles Iliya Krempeaux wrote:>> To take a slight detour into the (hopefully not too) abstract, what do>> people think the fundamental point of semantics in HTML is?>>>> I'd say Machine readability. >Sorry to be pedantic but what do you mean "machine readable"? All(conforming) HTML documents are "machine readable" in the sense thatthey can be parsed by machines, and no machine is capable of understanding the actual content, so presumably you mean something else.I mean so that a machine can understand what you are saying... what you mean.For example... I could write... And Jane Blow said... you are so cool. To which I said... I know.A machine (of today) isn't going to understand this. But I could mark it up with And http://jane.example.com/">Jane Blow said... http://jane.example.com/1234.html#xyz ">you are so cool. To which http://joe.example.com/">I said... http://jane.example.com/1234.html#zzz ">I know. And a machine would understand that alot better.Make sense? (Or should I explain more?... I'm being lazy by asking this... I just don't feel like doing alot of typing right now... but if it needs more explanation let me know.) See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Video (Was: How not to fix HTML)
Hello,On 11/1/06, Christoph Päper <[EMAIL PROTECTED]> wrote: *Ian Hickson*, 2006-10-30:>> Sure. FWIW, there's a lot of interest in browser vendors about> introducing> a element or some such (or maybe making browsers natively> support > video in , or both).I think it would be helpful to /explicitly/ allow content types(alias media types) in |type| of |object| to omit the subtype, e.g.: ~= +1 for something like that. ALOT of "normal" web developers have problems with MIME types. (They don't have them memorized. And don't know what MIME type corresponds to what file type.)I've done things where I've asked people to add a "type" attribute to 's... but "normal" web developers find this difficult. They know what they are dealing with is a "video"... but they don't know the different MIME types. Like: "video/mpeg" for .mpg files, "video/x-ms-wmv" for .wmv files, "application/ogg" for Ogg Theora files, etc. Simplifying it to allow type="video" would make life alot easier on web developers IMO. And alot of times, when I asked web developers to do this, I didn't care what the subtype was... I only cared whether it was a "video" or not. See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello,On 11/1/06, James Graham <[EMAIL PROTECTED]> wrote: Anne van Kesteren wrote:> On Wed, 01 Nov 2006 19:24:17 +0100, Christoph Päper> <[EMAIL PROTECTED]> wrote:>> And HTML5 isn't that semantically pure anyway. >> Where can it be improved?To take a slight detour into the (hopefully not too) abstract, what dopeople think the fundamental point of semantics in HTML is?I'd say Machine readability. [...]See ya -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello Christoph,On 11/1/06, Christoph Päper <[EMAIL PROTECTED]> wrote: *Henri Sivonen*, 2006-10-29:>> http://blog.fawny.org/2006/10/28/tbl-html/>>> * HTML has samp, var, and kbd. I use all of them and I am >> pretty much the only one who does.>> FWIW, I think and don't deserve to be in HTML and I am> not convinced that the use cases for could not be satisfied > by .I consider That's a really good idea! more semantic than the frequent alt="Foo">.Alas nobody is using it that way. (What kind of |rel| could one usefor this kind of links BTW?)See ya -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hello,On 10/31/06, Rimantas Liubertas <[EMAIL PROTECTED]> wrote: <...>> To get valid markup I must use a table tags if I want my layout to> *function* that way. There is no way to fake it. It took three minutes> to change the tags to table tags and the page functions perfectly now. > This is for the benefit of the users.Some case of non sequitur, imho.I am in "ban tables for layout" camp. If anyone want to use them forthis purposethey are free to use some other standard or do not use any standard at all... Weren't we talking about creaing new HTML elements for a grid layout before? (Or am I dreaming?)What ever happened to that?See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Video
Hello Henri,On 10/31/06, Henri Sivonen <[EMAIL PROTECTED]> wrote: On Oct 31, 2006, at 07:43, Lachlan Hunt wrote:[...] > It would be very nice to have a widely supported, non-proprietary, > patent free format on the web, which is also completely free of DRM.Agreed.> I would love to see Ogg Vorbis/Theora become as successful in the> audio and video market as PNG has for images, but the current > problem holding it back is the lack of implementation in the major> media players and browsers> Aside from the companies who have a stake in proprietary formats,> I'm sure they would like to because they could save money on > licensing fees.It isn't just the network effects of installed base (lack thereof)that are holding Theora back. Theora is not technically as advancedas H.264 or WMV9 (or even H.263 apparently). In general, a Theora- encoded video requires more CPU power for decompression than acomparable video encoded using a codec encumbered by the MPEG-LAportfolio. Also, to achieve similar subjective quality, you need morebits with Theora than with recent codecs encumbered by the MPEG-LA portfolio. It's true that Ogg Theora is far from ideal (given the recent advancements we've had). But we still use GIFs when PNGs are superior... because GIF are "good enough" in alot of cases. Even with Ogg Theora's short comings, having it be the defacto standard video format for video on the web (and even the Internet) would help things alot!!!We need something after all, that is unencumbed, to become the defacto standard Video format. And what else is there? Really... I think Ogg Theora is "good enough". See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Video
Hello,On 10/31/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Alexey Feldgendler wrote:> Flash player does not ship with browsers, at least not with every> browser, but this doesn't prevent Flash from being widely used. "Initially, the Flash Player plug-in was not bundled with popular web browsers and users had to visit Macromedia website to download it,but as of year 2000, the Flash Player was already being distributedwith all AOL, Netscape and Internet Explorer browsers. Two years later it shipped with all releases of Windows XP." -- Wikipediahttp://en.wikipedia.org/wiki/Adobe_Flash#HistoryBesides, Flash is one of the few successful plugins. Many others that have failed.Yeah, Macromedia did a good job of spreading their Flash plug-in.From a Internet & Web video point-of-view... Too bad Java applet support isn't ubiquitous any more. With Java you can write your own codecs. With Flash you can't. Although I was told Java has about 80% support still. So things like Cortado <http://www.flumotion.net/cortado/> still work in many many browsers still. See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Video
Hello,On 10/30/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Ian Hickson wrote:> On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:>> Would you be open to hearing suggestions about how to add native video>> and video player support?>> Sure. FWIW, there's a lot of interest in browser vendors about introducing > a element or some such (or maybe making browsers natively support> video in , or both).I don't like the idea of a element just for the purpose ofembedding video. What I think needs to happen is for browser vendors and plugin vendors to improve the usability and add better support forvideo formats. Places like YouTube and Google Video work around this bybuilding their own interface using Flash, which handles multiple formats seamlessly for the user.Not exactly. Flash players only play FLV video files. And that's it (AFAIK).Behind the scenses... server-side... other video formats a transcoded to FLV. The problem with Flash is that Flash is NOT a video. It's an "application" like Java applets. (Although Java has way way way more power than Flash.) The point is that potenially you do NOT have access to the video file(s) at all. And that is a big problem!!! With the current plugin architecture, each plugin provides it's own UI. So that, for example, a Quick Time video (.mov) gets the Quick Time UI and a WMV gets Windows Media Player. That's a bad user experience, thebrowser should provide a common UI for all videos, regardless of the format.As I'm going to mention more in my list... I'd recommend that web developers can create their of UIs... create their own Video Players. There could be a default styling. But web developers should be able to have full control of the look. Perhaps, to go along with the Audio() interface, we could have a Video()interface as well. Maybe it would be wise to introduce a MultiMedia()interface, which is then inherited by both the Audio() and Video()interfaces and extended by each with APIs specifically for their respective media. e.g. Video() could have an API for capturing a frameand exporting it as a JPG or PNG.The frame capturing would be cool (and useful).I guess I wasn't paying attention when the Audio interface was being discussed, because I totally missed it. Looking at it now, I'd make some alterations to it.For example, there's a difference between "pausing" and "stopping". (With "pausing" you still have your "position" and a "velocity" in the audio stream. With "stopping", each of those are null/nil.) And there should be different procedures for each. Also, there should be a way of playing at different speeds and playing backwards too.Previously, I've defined this as the "velocity" in APIs. A velocity of "1" is normal playing. A velocity of "-1" is playing backwards. A velocity of "- 2.5" plays backwards 2.5 times the normal speed. A velocity of "0.25" is playing forward at 1/4 the speed.Also... when implementing UIs, it's useful to have a "toggle()" procedure. Something that makes it "pause" if it is "playing". And makes it "play" if it is "pausing". Without this you have to keep track of the state of the player. (This is part of my item #6 on my list.) Those interfaces could also possibly be implemented on the and elements.Charles Iliya Krempeaux wrote:>> #1: A natively supported video format. (Like the way GIF's, JPEG's, and>> PNG's are natively supported.)Defining which video format for browsers to support is out of scope of the WHATWG and HTML5.That's unfortunate. However, I do agree that there needs to be a more widely supported format so that websites don't have to offer the user achoice (commonly WMV, Quick Time and Real).Getting a little off topic... but those aren't the main ones I've seen. I don't even see Real used anymore. (Maybe I'm not looking hard enough though, but) Certainly QuickTime and WMV are common. But (as I remember from a survey someone did on the Videoblogging mailing list) people are also procuding M4V (for iPods/iTunes), MP4 (for PSPs), DivX, and some people are even producing Ogg Theora. (I think there were some others too... but I don't remember off the top of my head.) If offered a choice, itshould only be to pick one suitable for their bandwidth. > Given this, I would suggest Ogg Theora be the natively supported video> format common to all browsers.It would be very nice to have a widely supported, non-proprietary,patent free format on the web, which is also completely free of DRM. I would love to see Ogg Vorbis/Theora become as successful in the audioand video market as PNG has for images, but the current problem holdingit back is the lack of implementation in the
Re: [whatwg] How not to fix HTML
Hello Lachlan,On 10/30/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Ian Hickson wrote:> Joe Clark wrote:>> http://blog.fawny.org/2006/10/28/tbl-html/FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-htmlThat link doesn't work. (I get a 404.)See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Video (Was: How not to fix HTML)
Hello,On 10/30/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: Hello,On 10/30/06, Ian Hickson < [EMAIL PROTECTED] > wrote: On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:>> Would you be open to hearing suggestions about how to add native video> and video player support?Sure. FWIW, there's a lot of interest in browser vendors about introducing a element or some such (or maybe making browsers natively supportvideo in , or both).(What's most needed right now in this area is probably implementationexperience.) I think there's a set of issues to look at with video and video players on the web. For the most part, these can be looked at and decided upon separately.#1: A natively supported video format. (Like the way GIF's, JPEG's, and PNG's are natively supported.) #2: Video players. (This would be embedding some kind of video screen in a webpage... possibly with a play/pause button, stop button, etc.)#3: Playlists. (A single video file just won't cut it.) #4:(Static or animated) thumbnails to videos.#5: When to pre-fetch and when NOT to pre-fetch videos (and "download" it at the last possible minute). #6: _javascript_ API for "playing", etc video.#7: Scrubbing though video#8: Alternate versions.(There's some other things that I'd describe ads more advanced... but I'll save those for now and see how people react to these first.) To make it easier to manage the conversation, I'll post about each of these in a separate e-mail.#1 on my list is... a natively supported video format common to all browsers.Thus... like the way all (GUI) browsers support GIFs, JPEGs, and PNGs. There should be at least one video format supported on all browsers. I made this #1 because I think this is the most important thing on this list. If I could only have one of these things on my list get implemented it would be this one.One of the biggest problems with video on the web (and probably video on the Internet in general) right now is that there is no universally supported video format. (Note, this doesn't mean there can't be other video formats too. This only suggests that there should be a baseline video format supported everywhere.)On the Videoblogging Mailing List < http://tech.groups.yahoo.com/group/videoblogging/>, the question about what video format to support comes up over and over again.And the answer that has to be given to them is that there isn't a single video format... but essentially they have to encode to many many different video formats, or else there will be people who can NOT view their show. Often, people will only encode in one format. Not really by choice. Not because they want to make it so certain people can't watch their show. But because they lack the skills or tools to encode in the other formats. Most of these publishers want everyone to be able to see their show though. (A natively supported video format common to all browsers would solve this problem.)Having said all that, I believe that whatever video format is choosen can NOT be encumbered. By patents or anything else. Such a thing is totally unacceptable.Given this, I would suggest Ogg Theora be the natively supported video format common to all browsers. It's designed from the beginning to be unencumbed. And implementations for it already exist under licenses that should make everyone happy. There's also existing tool sets that support it. And existing developer experience and knowledge about it.If you don't mind hearing me get onto a soapbox and rant about this particular topic, read this: http://maketelevision.com/log/why_ogg_theora_matters_for_internet_tv(Note... Dirac, Matroska, and NUT also exist. But neither of these are as mature as Ogg Theora.) See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Video (Was: How not to fix HTML)
Hello,On 10/30/06, Ian Hickson <[EMAIL PROTECTED] > wrote: On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:>> Would you be open to hearing suggestions about how to add native video> and video player support?Sure. FWIW, there's a lot of interest in browser vendors about introducing a element or some such (or maybe making browsers natively supportvideo in , or both).(What's most needed right now in this area is probably implementationexperience.) I think there's a set of issues to look at with video and video players on the web. For the most part, these can be looked at and decided upon separately.#1: A natively supported video format. (Like the way GIF's, JPEG's, and PNG's are natively supported.) #2: Video players. (This would be embedding some kind of video screen in a webpage... possibly with a play/pause button, stop button, etc.)#3: Playlists. (A single video file just won't cut it.) #4:(Static or animated) thumbnails to videos.#5: When to pre-fetch and when NOT to pre-fetch videos (and "download" it at the last possible minute). #6: _javascript_ API for "playing", etc video.#7: Scrubbing though video#8: Alternate versions.(There's some other things that I'd describe ads more advanced... but I'll save those for now and see how people react to these first.) To make it easier to manage the conversation, I'll post about each of these in a separate e-mail.See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] How not to fix HTML
Hello,On 10/30/06, Ian Hickson <[EMAIL PROTECTED]> wrote: Hey Joe,Joe Clark wrote:> http://blog.fawny.org/2006/10/28/tbl-html/[...] > This is a classic problem in HTML development: The people doing the work> are geeks with computer-science interests who do not understand, for> example, newspapers, or screenplays, or, really, print publishing in > general. In some obscure way, they disdain print publishing, as the Web> is not print. Indeed it isn't, but print has structures the Web doesn't,> and it doesn't have them because people like these refuse to acknowledge > they exist or simply refuse to consider them.Note that while it certainly is true that I'm a geek who doesn'tunderstand many things outside my sphere of interests, it is _not_ truethat such concerns are being intentionally ignored here. I encourge you and anyone else who has desires for what HTML should do to speak up.Would you be open to hearing suggestions about how to add native video and video player support?(I have alot to say about that. And there's alot of people and companies who would find it very very useful. Rather than doing all the kludges that are in use today.) See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Canvas lack of drawString method
Hello Stefan,(Like I said, I'm not an expert on this, but) For a specific issue... One thing that comes to mind is "Ruby" in the Japanese language.On 10/25/06,
Stefan Haustein <[EMAIL PROTECTED]> wrote:
Charles Iliya Krempeaux wrote:> I believe it starts to gets more complex when you get into> globalization. (Not that I'm an expert on that, but) More> thought may be needed to be put into this to make this work in a
> global sense (and not just with roman-based alphabets like ours.)Hi Charles,what precisely are you suggesting? Are some characters missing from UTF?Are the writing direction properties of CSS not sufficient to cover some
writing directions?To my knowledge concerning baseline/ascent/descent, non latin charactersare equal (kyrillic, greek) or simpler, but of course I may beoverlooking something, and I am always happy to learn anything new about
I18N and foreign languages (if it is a bit more specific than "I belivethere may be problems").Best regards,Stefan>> See ya>> On 10/25/06, *Stefan Haustein* <
[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>> Hi David,>> of course adding only textStyle and drawText() is much better than
> nothing at all! :)>> However, I would still prefer an API design that keeps it simple> to add> those methods later. Perhaps they could be included and simply return
> null if the requested information is not available (e.g. for a> dumb EPS> render target?). Also, if we do not have access to font metrics, I> think> we need an additional parameter for drawText() that specifies the
> alignment of the text relative to the reference point, as> illustrated in> the image below:>> http://www.developer.com/img/articles/2002/12/26/03fig12.jpg
> <http://www.developer.com/img/articles/2002/12/26/03fig12.jpg>>> Best regards,> Stefan>
> David Hyatt wrote:> > I'm very reluctant to expose font metrics and information (yet). I> > think once you start getting into specifying fonts, you open up> a can> > of worms that would make this sort of API addition a lot harder.
> >> > dave> >> > On Oct 24, 2006, at 4:05 PM, Stefan Haustein wrote:> >> >> Hi David,> >>> >> I think it is very important to be able to determine the rendered
> >> size of the text. Otherwise, there is no reliable way to make sure> >> things do not overlap. Also, some kinds of applications (flash-like> >> effects, labels expressing weight or distance, WYSIWYG text
> editors)> >> may require variable font sizes or styles.> >>> >> What do you think about> >>> >> context.textStyle = "barchart"; // style by reference
> >>> >> context.textStyle = { // set style directly> >> "font-size": "8px",> >> "font-family": "Monaco, monospace"
> >> }> >>> >> context.drawText(x,y,string); context.getFontAscent();> >> context.getFontDescent();> >> context.getFontLeading ();> >>
context.getTextWidth(string);> >>> >> Best regards,> >> Stefan> >>> >>> >>> >>> >>
> >> David Hyatt wrote:> >>> I think a drawText method would be extremely useful.> >>>> >>> Rather than specifying stylistic information explicitly (via a
> font> >>> object), I'd use a special parenthetical pseudo-element. thus> >>> allowing the author to specify the style as for any other> element on> >>> a page something like this...
> >>>> >>> canvas::canvas-text(barchart)> >>> {> >>> font-size: 8px;> >>> font-family: Monaco, monospace;> >>> }
> >>>> >>> and then the API would be something like:> >>>> >>> drawText(y-coord of baseline, "barchart", myText)> >>>
> >>> and letter-spacing/word-spacing would work, small-caps would> work,> >>> text-shadow would work, etc. etc.> >>>> >>> fitTextToPath might be an interesting API too.
> >>>> >>> dave> >>> ([EMAIL PROTECTED] [EMAIL PROTECTED]>)> >>>
> >>> On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:> &
Re: [whatwg] Canvas lack of drawString method
sues are not>>>> addressed at all.>>>>> Like I said, we want to leverage the browser's deep and complex >>>>> knowledge of text rendering as much as possible, and just take the>>>>> resulting pixel output as it would be shown to the user.>>>>>> - the implementation in actual browsers may be more complex than >>>>>> it seems because of problems with internal data structures for>>>>>> rendering hints and implicitly introducing the ability to render>>>>>> the same element twice. >>>>>> - what happens with contained plugins, canvas elements,>>>>>> self-references... all this stuff needs to be well-defined>>>>> Indeed. I know it's easy to state and there are edge cases. But we >>>>> could put limits on it like e.g. no plugins, no , and>>>>> still have something very useful for rendering text.>>>> So I assume we agree that the element rendering proposal would >>>> still need significant specification work and is probably much more>>>> difficult to implement. The element rendering approach may make>>>> working with bulk text simpler, but this case is already handled >>>> quite fine by HTML outside the Canvas element. By asking for too>>>> much, we may end up with nothing at all.>>>>>>>> Andrew has provided a clear and simple proposal that can easily be >>>> implemented without too much consideration of side effects. Putting>>>> labels on maps, precise text positioning, starwars-like 3d>>>> scrolling text, labels for game characters or in physics >>>> simulations, all the stuff that could only be done in a canvas>>>> element, is trivial to implement with the drawText() approach, but>>>> seems much more complex or impossible with the element rendering >>>> approach.>>>>>> Moreover, drawElement() would not solve the drawText problem for>>>>>> non-browser environments such as Rhino.>>>>> How are we anticipating might be used in a non-browser >>>>> context?>>>> Canvas and some other parts of the spec (e.g. connections) may make>>>> a lot of sense for _javascript_ outside of the browser context. This>>>> may be outside of the scope of WHATWG, but if we can take out some >>>> building blocks and use them somewhere else, this is at least a>>>> sign of good and modular API design.>>>>>>>> Best regards,>>>> Stefan >>>>>>>>>>>>>>>>>>-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Canvas lack of drawString method
Hello,There's also these ones...http://www.donfrehulfer.com/texttest.htmlhttp://caimansys.com/projects/canvas/digiclock.html http://andrewwooldridge.com/canvas/canvasfonts/testfonts.htmlOn a separate note... I've been thinking that it would be useful to have a program that could take a TTF font file and transform it into some _javascript_ that would draw the "strings" with the Bezier curve procedures that already has. See yaOn 10/24/06, Alfonso Baqueiro <[EMAIL PROTECTED]> wrote: This is the kind of hacks a drawString method can prevent.2006/10/24, Lachlan Hunt <[EMAIL PROTECTED]>:> Alfonso Baqueiro wrote:> > The canvas component is very promising, but the lack of drawString method > > could be a great error for its success, this lack is a huge limitation, how> > could you resolve this problem?>> Just for a bit of fun, I created a demo to show how it is already> possible to render text on canvas. This technique has certainly got > many limitations and could never be made as good as a native> implementation, but it works Firefox, Opera and Safari.>> http://lachy.id.au/dev/2006/10/canvas-text >> --> Lachlan Hunt> http://lachy.id.au/>-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] Canvas lack of drawString method
Hello Gervase,+1 for drawElement(e)(A drawElement(e) procedure sounds like a really good idea.)On 10/18/06, Gervase Markham < [EMAIL PROTECTED]> wrote:Alfonso Baqueiro wrote:> The canvas component is very promising, but the lack of drawString > method could be a great error for its success, this lack is a huge> limitation, how could you resolve this problem?I've suggested this in the past as a solution to this problem: why nothave a drawElement(elem) parameter? That way, you could build an accessible, readable version of the contentinside the tag, as alternative content, and copy labels oranything else into the itself with drawElement(label). So the same content serves both as the accessible version and the used version.This would give us great flexibility, because the text you do have iscontrolled with all the power of the existing CSS and browser font model, obviating the need for font controls or font objects on the API - which would inevitably be not as good as the CSS ones.And if browsers acquire downloadable font support, so does canvas. I would speculate wildly that it might even be easy to implement too.After all, I'm sure browsers have the ability to render the contents ofa tag to a drawing buffer...Gerv -- Charles Iliya Krempeaux, B.Sc .charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Canvas lack of drawString method
Hello Stefan,You'll probably need alot of info, about the font, to be able to really handle fonts properly.It's been a while since I've really written that kind of code.But just consider the concept of "kerning". Any API would need to expose that kind of info too. See yaOn 10/17/06, Stefan Haustein <[EMAIL PROTECTED]> wrote: Hi,I would like to second the drawString() request.It makes sense to have a simple API, but it should be balanced withapplication simplicity and readability to some extent. Doing CSS blackmagic to overlay text and a Canvas object just seems inadequate for something like axis labeling.As noted earlier by somebody else (did not find the mail...), we wouldalso need a simple Font object, but the minimum requirements seem rathersimple:Font Canvas.createFont (String cssFontProperties);Canvas.setFont(Font font) // set current fontCanvas.drawString(int x, int y, String text);Font Canvas.getFont() // current fontint Font.stringWidth(String s);int Font.getHeight (); // includes leadingint Font.getBaselinePosition();int Font.getAscent();int Font.getDescent();Best regardsStefan HausteinAlfonso Baqueiro wrote:> Hello Charles,> > 2006/10/17, Charles Iliya Krempeaux <[EMAIL PROTECTED]> [EMAIL PROTECTED]>>:> > Hello Alfonso,>> On 10/17/06, *Alfonso Baqueiro* < [EMAIL PROTECTED]> [EMAIL PROTECTED] >> wrote:>> The canvas component is very promising, but the lack of> drawString method could be a great error for its success, this> lack is a huge limitation, how could you resolve this problem? >>> I believe that some people's reason for not wanting to add it was> because of Accessibility concerns.>> Although normal text in a webpage... or even a text image (with > the "alt" attribute filled in properly) could be "read" by a> person with disabilities, text embedded in the canvas element> could not.>> Perhaps people need to think about how to add Accessibility to the > canvas while allowing a "drawString" procedure.>>> Well a drawString method in canvas can be used for drawing the axis> labels or values on a dinamic _javascript_ graphic, but is non sense an > aural reader read it, theres no way (yet) to read an image to a> blinded people, there are cases where is imposible the accessibility,> is imposible for a blind to play video games, and accessibility dont > stop the video games creation. In the case of images or the canvas the> alt attribute could do the job.>> See ya> -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/
Re: [whatwg] Canvas lack of drawString method
Hello Alfonso,On 10/17/06, Alfonso Baqueiro <[EMAIL PROTECTED]> wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the "alt" attribute filled in properly) could be "read" by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a "drawString" procedure. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/
Re: [whatwg] Forms and POST'ing to data: URL's
Hello Ian,One use case, from my point-of-view, was to allow for non-networked form submitsFor example, if you had a computer or device that did NOT have a network connection, and you did not have (and did not want to have or cannot have) a local HTTP server running. Then you could use such a data URL to make things happen.
Also, with the use of data URL's for 's, for 's, and for 's, you could have an entire HTML-based application contained in exactly one file. Which is again useful in situations where you do NOT have network access.
Also, it is useful to have the entire HTML-based application contained in "one file" when you want to put it into some other XML document. (Like in RSS, Atom, or XMPP/Jabber.)What really motivated me to think about it is that is that I was writing a blog post about how to create HTML e-mail signatures with hCards built into them.
I wanted to include a form to help them do this. The reader would fill in their name, e-mail address, etc, and it would generate HTML code they could use for their HTML e-mail signature.However, I didn't want the form to make a request back to my server. (Because people could be reading this in their feed reader were they have the blog post cached from my feed.) I wanted it to be entirely self contained within the blog post.
So, as you mentioned, one solution is _javascript_. However, _javascript_ has a couple problem. #1: It complex. (Yes... I'm lazy :-) ) #2: Not all blog readers will allow the execution of _javascript_.Also,... another reason against making a call on my server The blogging software I wrote works by having each blog post be a file. Each file is an Atom document. Not an Atom though. But an Atom . (And yes, it is legal to have an Atom as the root element.)
So having everything in one file is easier and simpler for me. (And again, yes, I'm lazy, and like things easy.) Preferably, I'd like to do 's, 's, and 's with data URL's.
See yaOn 8/24/06, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Wed, 26 Jul 2006, Charles Iliya Krempeaux wrote:>> >
>>> >> How would you get the value of "given_name" and "family_name" into the
> data URL?You can't, unless you use _javascript_, I think.> What I want is something like...>> > '%%{given_name}' and my family name is '%%{family_name}'. Sincerely,> %%{given_name} %%{family_name}">Interesting. What's the actual use case? I hadn't really envisaged data:being used for anything but debugging.
--Ian Hickson U+1047E )\._.,--,'``.fLhttp://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
-- Charles Iliya Krempeaux,
B.Sc.charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
___ Make Television
http://maketelevision.com/
[whatwg] Forms and POST'ing to data: URL's
Hello,
I was look at the "submitting and encoding form data set" for the "data: URL"...
http://whatwg.org/specs/web-forms/current-work/#for-data
... and noticed that (at least when I read it), there does NOT seem to
be a way to include values from multiple inputs.
Let me elaborate with an example. Consider the example of generating
some kind of letter where you fill in the blanks. (I'll show a rather
simple example here.)
How would you get the value of "given_name" and "family_name" into the
data: URL?
What I want is something like...
(Excuse any word wrap in the example above please.)
(Where %%{given_name} and {given_name} would include the value
from the input text box named "given_name". With the first form being
singly URI encoded, and the second form being doubly URI encoded.)
Is there any way of doing anything like this currently? (And if
not) Is there any plans on doing anything like this?
--
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
___
Make Televisionhttp://maketelevision.com/
[whatwg] Forms and POST'ing to data: URL's
Hello,I was look at the "submitting and encoding form data set" for the "data: URL"...http://whatwg.org/specs/web-forms/current-work/#for-data
... and noticed that (at least when I read it), there does NOT seem to be a way to include values from multiple inputs.Let me elaborate with an example. Consider the example of generating some kind of letter where you fill in the blanks. (I'll show a rather simple example here.)
How would you get the value of "given_name" and "family_name" into the data URL?
What I want is something like...
(Where %%{given_name} and {given_name} would include the value from the input text box named "given_name". With the first form being singly URI encoded, and the second form being doubly URI encoded.)
Is there any way of doing anything like this? Is there any plans on doing anything like this?-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @
gmail.comdeveloper weblog: http://ChangeLog.ca/___ Make Television
http://maketelevision.com/
Re: [whatwg] Where did the "rev" attribute go?
Hello Matthew,On 7/11/06, Matthew Raymond <[EMAIL PROTECTED]> wrote: Charles Iliya Krempeaux wrote:> Perhaps I can illustrate what I mean with an example.>> (But first note that people can make up their own values for "rel" and> "rev". But anyways, here's the example.) >> Let's say in a page, I have the following HTML code...>> > http://show.example.com/">Example IPTV> Show> http://show2.example.com/">Another Example > IPTV Show> (Not the best example, because "show" can be a verb.)> The semantics here are The class-xoxo (on the ) says that I'm > giving a list here. And the class-shows says this thing is/has> "shows". (So basically, I'm listing shows.) Wouldn't this be a lot like using |rel| to define a media type?Granted, it's more the example you're using than your general concept that's causing the confusion.Perhaps it's a poor example. But what I've gotten from the specs is that the "rel" attribute can be used in this way. > The rel-show inside the "list of shows", says what's at the end of the> "href" is a "show" for the list of "shows".>> So,... if you go to the URL in the "href", you get a whole HTML page > with all sort of stuff in there. But what is the "show"? The whole> page? Just part of it? How about the element that has the ID that's in the URL in the |href|attribute? That would take you directly to the element in question. I think |xml:id| is pretty much a standard now.Yeah, that would definitely be better from a developer's point-of-view. And there are times when you do do that.But sometimes, you can't do that. Perhaps the HTML fragment that you want has no "id" on it. (And you have no control of the page any you can't add it.)Or, even if it does have it, perhaps linking to that fragment makes for poor usuability. And in terms of usability it's better to link to the page (without the fragment identifier -- without the "id".) ( I.e., jumping to that part of the page would be "bad" from the usability point-of-view Or maybe doing so skips the ads on the page, and would mess up the business relation you have with that publishers.) Or perhaps the thing you want there is spread out into multiple HTML fragments on the page. (I show an exampe of this later on in this e-mail.) > Well, I then search the page for [class "show"]. (I look for something> inside the page with a class with the same token/name use in the "rel"> that linked there.) What if the web page you're linking to has the class name "JoeMunchey" instead of "show"? You're requiring people to examine theHTML of the target page in order to use this feature. The |rel|attribute doesn't have this requirement; you need only to know what the nature of the target page is.What I'm saying is that peolpe would choose their "rel", "rev", and "class" names ahead of time. And everyone would agree on them. And you'd have a (defacto) standard created. (A Microformat possibly.)So that people who made a "show" (would be aware of the standard ahead of time and) would mark up their pages with the class-show. (And anything else the standard required or asked for.) And people would make their "list of shows" with rel-show point to each show in their list.But,... people would agree on these ahead of time.For an example that's gained some popularity, look at hCard. http://microformats.org/wiki/hcardPeople wanted to semantically denote "contact info". So they choose a set of class names to use (to do this) and some rules about them. Creating the standard is a somewhat arbitrury process. And requires humans to do it.Although with opaque semantics, like the "rel" name matching the "class" name, you don't need a human intervention to parse much of it. Does what I'm saying make sense? Or should I explain it more? > If I find (just) one, then great, that's probably what I want to > concentrate on. (The other parts of the page are probably [irrelevant].)> If not, I'll probably have to concentrate on the whole page.>> (This is the idea of opaque semantics that I was talking about before.) >> Does that clear it up? It seems like some sort of a link-to-class, rather than linking to aURL + ID. I don't see the point. How is anyone going to see this ontheir browser? Will it open multiple tabs? I'm not thrilled about giving authors the ability to open multiple tabs or windows in my browserwithout my consent. Will it create a drop-down that lists all theelements that are part of the class? This will not give me a
Re: [whatwg] Where did the "rev" attribute go?
Hello Matthew,On 7/11/06, Matthew Raymond <[EMAIL PROTECTED]> wrote: Charles Iliya Krempeaux wrote:> Hello Matthew,>> That clears things up a bit.>> But, if the intent is to really get rid of confusion then There's> actually 2 things I noticed confuse people. >> #1: That the label you pick for the "rel" (or "rev") needs to be a> noun. (I do understand why... at least I think I do... so that you can> use the same label in the "class" attribute. But it makes things > difficult for some people.) I don't know what you mean about |class|, since it seems redundant.Furthermore, |rel| has predefined semantic value in HTML 4.01, whereas|class| has user-defined and/or proprietary semantic value at best. However, you are correct that it needs to be a noun, because it's the_name_ of a relationship.Perhaps I can illustrate what I mean with an example.(But first note that people can make up their own values for "rel" and "rev". But anyways, here's the example.) Let's say in a page, I have the following HTML code... http://show.example.com/">Example IPTV Show http://show2.example.com/">Another Example IPTV Show The semantics here are The class-xoxo (on the ) says that I'm giving a list here. And the class-shows says this thing is/has "shows". (So basically, I'm listing shows.) The rel-show inside the "list of shows", says what's at the end of the "href" is a "show" for the list of "shows".So,... if you go to the URL in the "href", you get a whole HTML page with all sort of stuff in there. But what is the "show"? The whole page? Just part of it? Well, I then search the page for class-show. (I look for something inside the page with a class with the same token/name use in the "rel" that linked there.) If I find (just) one, then great, that's probably what I want to concentrate on. (The other parts of the page are probably irrelevent.) If not, I'll probably have to concentrate on the whole page.(This is the idea of opaque semantics that I was talking about before.) Does that clear it up?(This is what I imagined the developers of these things originally thought up.) > #2: That "rel" (and "rev") represent a relation between the two. Often> people seem to want to "classify" what's at the end of the "href".> (Instead of specifying a relation.) Perhaps a new attribute is needed. > Perhaps "hrefclass". I would think something like "linktype" would be more appropriate.That said, |rel| is pretty much already corrupted to mean that, and ifwe introduced another attribute for the purpose of link types, it would either go unused for backwards compatibility reasons or it wouldsupplant both |rel| and |rev|.I suggested "hrefclass" because we already have things like... "lang" and "hreflang". It just seemed to follow the same style. (Since this seems to be just like the "class" attribute, expect we are applying it to what is at the end of the "href"... so "hrefclass".) See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/___ Make Television http://maketelevision.com/
Re: [whatwg] Where did the "rev" attribute go?
Hello Matthew,That clears things up a bit.But, if the intent is to really get rid of confusion then There's actually 2 things I noticed confuse people.#1: That the label you pick for the "rel" (or "rev") needs to be a noun. (I do understand why... at least I think I do... so that you can use the same label in the "class" attribute. But it makes things difficult for some people.) #2: That "rel" (and "rev") represent a relation between the two. Often people seem to want to "classify" what's at the end of the "href". (Instead of specifying a relation.) Perhaps a new attribute is needed. Perhaps "hrefclass". See yaOn 7/8/06, Matthew Raymond <[EMAIL PROTECTED]> wrote: You make the argument that people might be using |rev| intentionallyfor some values and the the statistical method used by Goggle doesn'tmake that determination. Let's look at the two most common uses. If you look at |rev="made"|, the most common use of |rev|, it's pretty clear that the use is intentional. However, |rev="made"| ispretty much equivalent to |rel="author"|, which is nearly as common, sothe impact of eliminating |rev="made"| is minimal. If you look at the following link, note that |rev="made"| is the only use of |rev|mentioned, by the way:http://www.htmlhelp.com/reference/wilbur/head/link.html The second most common usage is |rev="stylesheet"|. Since CSS stylesheets don't use HTML, let alone and , we can safely assumethat this is, in fact, either the result of confusion by the author or a spelling type, and as you pointed out, a typo is unlikely. This reallydoes suggest a genuine problem with people not understanding thedifference between |rel| and |rev|, since |rel="stylesheet"| is the most common use of |rel|. I really wish we could see more data on that, though. One of the problems with |rev| is that it's supposed to share valueswith |rel|, but in reality many of these values are either have narrow use cases for |rev| or are completely unusable, such as "stylesheet" and"icon". In my estimation, this will eventually result in a proliferationof values that favor a specific value. In fact, that's what we've seen, since most values are |rel|-centric.Charles Iliya Krempeaux wrote:> For example, I tend to use rev-author, rev-comment, and rev-tag quite> [a lot]. These aren't typos; these are intentional. And I do understand > what each means and am using them properly. None of the values you mention are defined in HTML 4.01, andconsidering you are the one asking for |rev| to be included in "HTML 5",I don't think you can consider yourself a typical author. -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Television http://maketelevision.com/
Re: [whatwg] Where did the "rev" attribute go?
Hello,On 7/5/06, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Thu, 6 Jul 2006, Tore Eriksson wrote:[...] > As for myself, I use the "rev" attribute in an internal project (sorry,
> no link) at work. I have to agree with Charles/Iliya that the> recognition of "rev" is probably going up in the future if the adaption> of new microformats continues.It certainly can't go down.
:-) > > On the contrary, I would argue that we should get rid of it as fast as
> > possible, so that we don't scare away authors who are becoming> > "semantically minded" by making the language more complicated than> > absolutely necessary.>> I have to disagree here. Removing the complexity in the HTML
> specification just moves it to the semantic application where the> "semantically minded" users have to agree on what the corresponding> inverse relations are. In my opinion the HTML spec is the place where
> this distinction can be kept with the least amount of "interfering"> complexity. As your survey shows, there is not a lot of confusion about> "rev", just some people having problems with spelling the "rel"
> attribute. I think there would probably have been a lot of "herf"> attributes out there if they were not discovered as easily as they are.The point is not just that people mis-use the rev attribute; the point is
that with the exception of a single value ("made"), people *typo the "rev"attribute more often than they intentionally use it*.It's difficult for me to see how they could "typo" it. The "L" key and the "V" key on my keyboard at least aren't anywhere near each other. (It would suggest to me that if they wrote "rev" instead of "rel", then they either "meant it" or they "don't understand the difference".)
What makes you so sure they are making spelling mistakes? Or that they didn't actually mean it and aren't using it properly?For example, I tend to use rev-author, rev-comment, and rev-tag quite alot. These aren't typos; these are intentional. And I do understand what each means and am using them properly.
Is the system that generated that report able to "know" that I use them properly? Or did it just assume that they must have been mistakes?
Another interesting statistic: people use rel="made" once for every 2.2instances of rev="made".(Sorry if this is in that report you referred us to, but I didn't notice it)
How do you know that those usages of rev-made or rel-made were mistakes? How do you know that they weren't intentional and weren't accurate?Was the system that generated the report able to figure out which ones were "good" and which ones were "bad"?
That is *far* more frequent a mistake than othertypos (the
Re: [whatwg] Where did the "rev" attribute go?
Hello Lachlan,On 7/5/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Charles Iliya Krempeaux wrote:> What happened to the "rev" attribute?The problem with the rev attribute is that it's difficult for authors tounderstand the concept of a reverse link relationship; and compared with rel, it's hardly ever used.There's only one use of rev that I'm aware of which is listed onmicroformats.org. It's for vote-links, but I don't think thoserelationships should be used anyway. It would be a shame to get rid of it now, now that web developers are starting to become "semantically minded".Sure no one is using it that much right now. But developers seemed to only recently awaken to the idea of adding semantics into HTML. (And it seems to be catching on more and more.) As developers start building semantics into web technologies, their going find that they need the "rev" attribute. (Not sure if that would be enough "justification" here to keep it. But since we already have it, it would be nice to keep it.) For example, I'm interested in trust metrics and reputation, so I consider a "rel" and "rev" to work hand-in-hand to establish this.For a real life example, consider these "community marks" people have been talking about. People want to essentially say someone is a member of a group. Let's use the Microformats.org group for example. Well, if I wanted to claim that I'm a member of that group, then I could put a Microformats badge on my blog, and link it to the Microformats.org website.But, being semantically minded, I'd link it like this:http://microformats.org/"> http://microformats.org/image/badge.png" alt=" Microformats.org" />(Note the rev-member.)Now that's great and all, but anyone can put a badge like that on their site. How do you know you can trust that?Well, what if the Microformats.org website had a members page, and linked to all their members, including my blog with the following: http://changelog.ca/"> Charles Iliya Krempeaux (Note that we are using "rel" here, instead of "rev" like before. Also note that the exact same label was using -- "member".)Well then we'd know that we trust this relation, because we have the same relation being asserted both ways. (Or at least can trust it more than if only one page was asserting the relation.) Without the "rev", we could still do this with "rel" however, the exact same label could NOT be used. And then any kind of system to analyse this would have to understand what this labels actually meant and know what the "reverse relation" name was. That is essentially my personal reason for wanting "rev". So that the exact same label can be used no matter what the direction of the relation. (That way a generic parser and query engine can be written for this type of stuff, even if the system does NOT understand the meaning of the labels.) > Neither the or element seems to have it anymore... I think it should still be present, but it's semantics would need to beclarified and explained. We should probably also identify some real usecases where it is actually useful for authors. I'm using it for trust metrics and reputation. (But that's just me and the software I write :-) ) > The "rev" attribute is important for allowing what I call "opaque> semantics".Can you more clearly define what you mean by "opaque semantics"?Think about XML (as compared to SGML-based HTML). One of the design goals for it was to make it so that a generic parser could be written for it without knowing anything about the meaning of the elements/tags. This was accomplished by requiring lone elements -- elements without a closing tag -- to have a "trailing slash". So, for example, you would NOT write "" or ""; but you would write "" and "". This meant that the semantics of the elements/tags could be opaque. A generic XML parser didn't need to know that a "" element did NOT have an ending tag.In fact, anyone can create their own custom XML-based language, and any XML parser will be able to handle it properly. In the same way, I'd like to keep this kind of advantage with typed links. (I.e., keep this kind of advantage with linked that use "rel" and "rev".)Analysing all these typed links (spread out across the web), you can create a graph connecting URI's. And the edges of the graph would have these labels and which side of the URI asserted the relation. With the "rev" attribute, the exact same label can be used. The semantics of the label can be opaque, but the system for analysing all this will work anyways.So, for example,... if the page http://z.example.com/ had
[whatwg] Where did the "rev" attribute go?
Hello,(I didn't search the archive extensively to see if this came up before, but)What happened to the "rev" attribute?Neither the or element seems to have it anymore... http://whatwg.org/specs/web-apps/current-work/#the-linkhttp://whatwg.org/specs/web-apps/current-work/#the-aThe "rev" attribute is important for allowing what I call "opaque semantics". With "opaque semantics", software can form a graph of relations without needing to understand what the labels (used in the "rel", "rev", and "class" attributes) actually mean. They just "connect the dots", so to speak, based on matching labels. See ya-- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/___ Make Televisionhttp://maketelevision.com/
Re: [whatwg] hrefclass attribute ? -- semantics token reuse
Hello, On 11/27/05, ROBO Design <[EMAIL PROTECTED]> wrote: > On Sun, 27 Nov 2005 00:28:49 +0200, Charles Iliya Krempeaux > <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > This is kind of a follow up to a previous post of mine: > > > > rel/rev for ? > > http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-November/005039.html > > http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-November/thread.html#5039 > > > > Now, although I still think "rel" and "rev" attributes on the > > element would be useful, I did note (to myself) that in some cases > > "rel" and "rev" were not what I really wanted. "rel" and "rev" > > specify semantics between (all or part of) the document they are in > > and the resource the "href" (or "action") attribute points to. (At > > least that's my understanding of it.) > <...> > > Hello! > Best description of rel and rev attributes I ever read is: > http://microformats.org/wiki/rel-faq Thanks. (I've already read it though.) > <...> > > For purposes of (semantic) token reuse, it would be nice if there was > > something like an "hrefclass" attribute. For example, let's say we > > had: > > > > > > a > > b > > c > > > > > > Now, lets say that instead of including this in our document, that we > > wanted to defer this to somewhere else. Then having something like > > the following would be very useful. > > > > http://example.com/shows";>... > > > > Now, it's true that with the "class" attribute by itself we could do > > something like: > > > > http://example.com/contact";> > > > > or: > > > > http://example.com/contact";> > > Shouldn't these last two links have href="http://example.com/shows";, like > the first one? Is it a mistake or is it on purpose? Sorry, that was a mistake. They all should have been "http://example.com/shows";. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
[whatwg] hrefclass attribute ? -- semantics token reuse
Hello, This is kind of a follow up to a previous post of mine: rel/rev for ? http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-November/005039.html http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-November/thread.html#5039 Now, although I still think "rel" and "rev" attributes on the element would be useful, I did note (to myself) that in some cases "rel" and "rev" were not what I really wanted. "rel" and "rev" specify semantics between (all or part of) the document they are in and the resource the "href" (or "action") attribute points to. (At least that's my understanding of it.) For example: http://example.com/feed"; /> http://joe-blow.example.com/";>... Now, sometimes you just want to specify semantics about the resource at the end of the "href" (or "action") attribute without there necessarily having to be a relation (between the 2 resources). Here's an examples where we can specify semantics about the resource at the end of the "href": http://example.com";>... (The important part in that example is the "hreflang" attribute.) This would tell you that the resource indicated by "http://example.com"; has a base language of "Canadian English". Here's another example: http://example.com/test.torrent";>... (The important part in that example is the "type" attribute.) This would tell you that the resource indicated by "http://example.com/test.torrent"; has a content type of "application/x-bittorrent" We could also show similar examples for the element. Like: (Here we have the familiar "rel" specifying semantics, in addition to "type" and "media", about the resource indicated by the "href" attribute.) Also, we could show examples for the element with respect to the "action" attribute; the element with respect to the "cite" attribute; the ,
Re: [whatwg] rel/rev for ?
On 11/7/05, Mike Dierken <[EMAIL PROTECTED]> wrote: > > > > > Yet, I have to add that what we've suggested is (almost) > > useless. That's because the WA 1.0 specification already > > contains something that can solve what we wanted: profiles [1]. > > > > [1] http://www.whatwg.org/specs/web-apps/current-work/#profile > Can the 'class' attribute have multiple values? If not, then a new attribute > would be needed, unless we overload the use of 'class' for presentation with > the use of 'class' for semantic purposes. > Yes, a "class" attribute can have more than one value. For example, you could do something like: You just put a space separated list in there. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg] rel/rev for ?
Hello, On 11/5/05, ROBO Design <[EMAIL PROTECTED]> wrote: > On Sat, 05 Nov 2005 00:17:27 +0200, Charles Iliya Krempeaux > <[EMAIL PROTECTED]> wrote: > > > Hello, > > > <...> > > > > Let me ask you some questions. (Your answers will help me know how to > > explain things better.) [...] > > * Do you think being able to provide semantics between 2 resources > > -- between 2 URI's -- is important? > > Yes, but not really for . > > Reason: generally speaking, an URI specified in the ACTION attribute of > the is not a web page that shows general information, good for web > crawlers nor the like. I wouldn't like bots going crazy in my s :). I think I see one thing I didn't explain properly. Web crawlers would NOT "submit" forms. But they would discover them. In essence, "rel" and "rev" based formats on the element would allow web crawlers to discover API's. And (web crawlers or user agents, etc) could present these forms to the user, and allow the user to fill them in and "submit" them outside of the web page they are embedding in. Essentially, "rel" and "rev" based formats on the element could allow you to turn the element into a kind of IDL. Consider a blog post. We have rel-author to specify the author blog post. We have rel-tag to specify the keywords phrases the author tagged the blog post with. We have rel-license to license of the blog post. (And all these can be done within the body of the blog post.) But how do you specify the API to post a comment to the blog post? How do you specify the API to change how you tagged the blog post? (Having "rel" and "rev" based formats on the element could allow you to do this.) [...] > > > * Do you think that be able to use other HTTP methods, other than > > GET, is important? > > In this case, not. The way I see it, web crawlers, extensions, user > scripts, user agents and the like can use the URIs of any resource, based > on the REL. For example, rel="author": this *should* give an URI to the > author of the web page, but how would this work with a ? Would you > require it to use POST or another method? Forms are more complex than > simple links, they require user interaction (fill the fields and most > likely a JavaScript on the page that validates the values). > > Also, forms are not for "general availability", in the sense of ... web > crawlers should *not* try to submit them (that's what the bad spam bots do > when trying to post spam comments). Again, I am NOT suggesting that web crawlers fill them in. I am suggestion that web cralwers use "rel" and "rev" formats on 's to discover API's. [...] > > (One thing though. Re-reading my message over, it seems to kind of > > have a "rude" connotation. But please note that is not my intent.) > > True, but no problems :). > > My general idea is this: I'm not against adding rel/rev to , but I > currently do not see any precise example of a use case. What's driven me to suggest it is to allow for the discovering of API's. So that a element with a "rel" or "rev" could act like an IDL. > Also, you need to take into consideration the implications of having > rel/rev for . Could you elaborate on this please. [...] See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg] rel/rev for ?
Hello, On 11/4/05, ROBO Design <[EMAIL PROTECTED]> wrote: [...] > Well ... creative uses ... might be there for just about almost any tag > with a rel= attribute. > > Still not convinced :). Let me ask you some questions. (Your answers will help me know how to explain things better.) * Do you see that "rel" and "rev" based formats have important uses beyond just keyboard shortcuts? * Do you think that semantics embedded into HTML is important? * Do you think being able to provide semantics between 2 resources -- between 2 URI's -- is important? * Do you think that web crawler usage or "rel" and "rev" based formats is important? * Do you think that user script usage or "rel" and "rev" based formats is important? * Do you think that extension usage or "rel" and "rev" based formats is important? * Do you think that be able to use other HTTP methods, other than GET, is important? * Do you think that being able to attach semantics to resources -- to URI's -- accessed through HTTP methods, other than GET, is important? * Do you think that being able to parameterize a "request" is important? (One thing though. Re-reading my message over, it seems to kind of have a "rude" connotation. But please note that is not my intent.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg] rel/rev for ?
Hello, On 11/4/05, ROBO Design <[EMAIL PROTECTED]> wrote: > On Fri, 04 Nov 2005 21:10:31 +0200, Charles Iliya Krempeaux > <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > (Don't know if this has come up before. I kind of lurk in this list > > :-) but ) > > > > The "rel" and "rev" attribute are very useful for adding semantics to > > both the anchor element -- -- and the link element -- . > > > > I'd like to suggest that form element -- -- get both "rel" and > > "rev" attributes. > > > > > > See ya > > Interesting suggestion. I can't help but wonder what exactly would this > change to the "user experience". Rel for LINK and A is changing the user > experience in user agents, because they can provide a "fixed" set of > keyboard shortcuts (mouse gestures or whatever) for going to the > previous/next page, help, home, author, etc. > > What are your ideas about this? What would you like user agents to do > based on various rel= attributes? There's a number of different "use cases" that this would be very useful for. I'll try an list some of the ones I think are important. In writing "user scripts" and "extensions" it is often desirable to look for "semantics" in a page. For example, consider the semantics given by rel-license <http://microformats.org/wiki/rel-license>. rel-license provides a way of specifying a license for either the whole "document" or part of the "document" it is in. (It's usually used in the element.) There is a Mozilla Firefox extension called MozCC <https://addons.mozilla.org/extensions/moreinfo.php?id=363> which will look for rel-license in a page, and if the URL in the "href" of the rel-license element points to a CreativeCommons license, it then displays "icons" that describe the license. Also, Mark Pilgrim has written a (greasemonkey) user script <http://diveintomark.org/projects/greasemonkey/rellicense/> that can detect and "handle" a very large number of licenses. Further, web crawlers (and search engines) can make use of this license information. (For example, Yahoo! has a way of searching only within stuff that are licensed under a CreativeCommons license -- http://search.yahoo.com/cc ) Also, one could even consider the semantics given by XFN <http://gmpg.org/xfn/>. (It is rel-based format on the element.) Or any of the other many "rel" and "rev" based formats on the and elements. (I can list more if you want to hear them.) (So hopefully I've shown that "rel" and "rev" based formats can be useful beyond just making "keyboard shortcuts" in the user agent.) One of the restriction with and based "rel" and "rev" formats is that you implicitly require the HTTP resource (in the "href" of the or ) element, to be accessed via an HTTP GET. With a element, you are not restricted by this. With the element you can use other HTTP methods (by specifying the method you want to use in the "method" attribute of the element). For example: Also, another restriction with and based "rel" and "rev" formats is that you have no way of "parametrizing" things. But with a element you can. (As shown with the example above too.) Those who have been touting using HTTP how it was designed to be used... although their calling it REST for some reasons... would likely find this type of thing useful too. Also, those that are trying to add increased semantics to HTML under the Micformats banner -- http://microformats.org/ -- would also find this useful. This could be used for user agents, for user scripts, for extensions, and for web crawlers. (There's probably more creative uses for it too.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
[whatwg] rel/rev for ?
Hello, (Don't know if this has come up before. I kind of lurk in this list :-) but ) The "rel" and "rev" attribute are very useful for adding semantics to both the anchor element -- -- and the link element -- . I'd like to suggest that form element -- -- get both "rel" and "rev" attributes. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello,
On 10/25/05, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-10-25 at 14:24 -0700, Charles Iliya Krempeaux wrote:
> > With web browsers, there are only 2 ways of doing a POST. (At least
> > only 2 ways I can think up right now :-) )
> >
> > #1 is though an HTML form. When a user submits an HTML form, they are
> > fully aware of it. And the browser has a chance to tell the user they
> > are POST'ing to another domain. (Which could be a social hack
> > attempt.)
>
> Yes, but look:
>
> http://example.com/delete"; method="post" id="deleteForm">
>
>
>
>
>
> window.onload = function() {
> document.getElementById('deleteForm').submit();
> }
>
>
> No current browser I tested displays a warning. Most display it once,
> the first time a POST is actioned after the browser is installed, but
> default to never displaying it again.
That's a good point.
See ya
--
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
___
Never forget where you came from
Re: [whatwg]
Hello, On 10/25/05, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote: > On Tue, 2005-10-25 at 14:06 -0700, Charles Iliya Krempeaux wrote: > > Perhaps the best way of handling this is to use a totally new HTTP > > method (other than "GET" or "POST"). Maybe "PING". > > > > That way you don't have to worry about people screwing things up or > > hacking due to POST'ing (of a URL like the flickr URL you gave). > > That Flickr URL was a GET. It's a non-issue anyway -- using a POST does > not offer any additional ability to "screw things up" or "hack". That flickr URL may have been via an HTTP GET, but many server-side scripting languages treat "parameters" from a GET request and a POST request the same. I.e., many server side scripts are written so that they are indifferent to how they receive the "parameters" we send them. For example, in PHP we have a "super global variable" called $_GET that contains all the parameters from an HTTP GET request. So, if we had a URL like: http://example.net/doaget.php?a=x&b=y&c=z Then we would have: $_GET['a'] == 'x' $_GET['b'] == 'y' $_GET['c'] == 'z' Likewise, with an HTTP POST, we have a $_POST "super global variable" that contains all the parameters from the HTTP POST request. So, if we made a call with a form like: http://example.net/goapost.php";> Then we'd have: $_POST['d'] == 'abc' $_POST['e'] == 'xyz' And if everyone who wrote PHP server side scripts used these -- use $_GET and $_POST -- then we'd have no problem. (We can easily tell the difference between "parameters" from an HTTP GET and an HTTP POST.) However, $_GET, $_POST, and other "sub global variables" were NOT originally part of PHP. Originally, "parameters" from an HTTP GET and an HTTP POST we simple put in normal variables (with the name). So, from the previous HTTP GET example, we'd just have: $a == 'x' $'b == 'y' $c == 'z' And, from the previous HTTP POST example, we'd just have: $d == 'abc' $e == 'xyz' With this method of getting "parameters", there's no (easy) way of telling the difference between HTTP GET "parameter" and HTTP POST "parameters". So if you we hit the URL: http://example.net/goapost.php?d=abc&e=xyz (Note, this is the same script as from our HTTP POST example.) Then we'd still get: $d == 'abc' $e == 'xyz' And the script... which was suppose to be POST'ed to... would still run and execute the same. And yeah, I know this is a problem with how people code PHP scripts, and not really an HTTP or HTML problem. But it's still a problem we might want to consider. [...] See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, On 10/22/05, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote: > On Sat, 2005-10-22 at 20:25 +1000, Lachlan Hunt wrote: > > It could be defined in reverse, where the ping attribute (probably given > > a more suitable name, but I'll use ping for now) could be advisory > > information about the final destination and the href attribute defines > > the ping destination, such that following the href attribute would > > perform a redirect, but WA1 UAs could use the URI in the ping attribute > > to notify the user of the final destination (such as displaying it in > > the status bar). > > Or the UA could just do a HEAD request for the URI in the /href/ > attribute and display the contents of the Location: header if the > response status is 3xx. We don't need a new attribute for this. The HTTP "HEAD" method really doesn't give you the semantics of what you are trying to do. "POST" would be better than "HEAD" IMO, since it conveys semantics more closely to what we mean. However, I don't really like "POST" since it allows for all kinds of "social hacking". IMO, using a new HTTP method would probably be better. Maybe "PING". See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, On 10/22/05, James Graham <[EMAIL PROTECTED]> wrote: [...] > So why not enforce this case by making the client do a redirect as soon > as it receives a response from the original URL: > > > > On receiving a response from tracker.cgi the client would redirect to > destination.html, irrespective of the contents of the response. It would > allow the correct destination to be displayed in the status bar which, > as far as I can tell, is the only merit of the original 'ping' proposal, > but still has the disadvantage that no-one would use it (since a UA > could easily disable contacting tracker.cgi, making it useless for > advertisers). It does, however, have a reasonable backward > compatibility story (tracker.cgi would typically take a URL parameter > which it would redirect to). The big problem is that it seems horrible > to implement, as one has to have special handling at the network level > for requests initiated from a link with a redirect attribute. One disadvantage of this is that you do not have multiple pings. (Which is often needed for advertising situations.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, On 10/21/05, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote: [...] > > > If you can come up with a reason why it's not safe, I'd like to hear it. > > My initial reaction was to be concerned about a malicious link that > > triggered a POST for a resource that becomes modified or deleted - like > > href="http://www.flickr.com/photos/dierken/?delete=39177102&magic_cookie=528 > > 479cac210fc6z837c0ac708334fe6" > > I would certainly hope that Flickr requires authentication before an URL > like that had any effect, in which case the developer of the website > would only be able to delete their own photos, or photos of those whom > they had stolen the authentication details for. This is not exactly a > new problem. Even with that, this kind of social hacking that can become at the least "annoying"... or in some cases could be a critical problem! It could used to send SPAM (when POST'ing somehow causes e-mail to be sent). With web browsers, there are only 2 ways of doing a POST. (At least only 2 ways I can think up right now :-) ) #1 is though an HTML form. When a user submits an HTML form, they are fully aware of it. And the browser has a chance to tell the user they are POST'ing to another domain. (Which could be a social hack attempt.) #2 is with XmlHttpRequest. But XmlHttpRequest isn't able to access other sites AFAIK... so this kind of thing isn't an issue with it. > > (Those freaking blockheads at Flickr just > > deleted my picture when I pasted that URI into the browser window. Losers - > > when will they realize that an anchor is not a UI widget. Thank goodness > > that I don't have a pre-fetch utility running or I'd lose all my vacation > > photos.) > > > > But of course anybody that can cause that extra attribute to appear on an > > anchor, likely has enough control to do some damage anyway. > > Exactly. If Flickr wanted to delete your photos, I don't think they'd > bother to try to fool you into clicking on a link. They'd just delete > them. It's not about Flickr doing it. But other's causing you to do stuff (like deleting your own photos, or sending e-mail, or making a splog post, etc) when you don't actually want to. Conceptually (at least from my point-of-view) POST'ing is suppose to require a user's approval. (XmlHttpRequest kind of gets around that requirement, but you are NOT allowed cross-domain access via XmlHttpRequest, so it is actually not a problem.) Developers should feel safe in the assumption that mutable operations on their site will not happen without the user knowing about it (due to their browser telling them). To get around this whole issue we could just use a totally new HTTP method (other than "GET" or "POST"). Maybe "PING". See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, Perhaps the best way of handling this is to use a totally new HTTP method (other than "GET" or "POST"). Maybe "PING". That way you don't have to worry about people screwing things up or hacking due to POST'ing (of a URL like the flickr URL you gave). See ya On 10/21/05, S. Mike Dierken <[EMAIL PROTECTED]> wrote: > > > > It definitely should be a POST, because the action performed by it is not > idempotent. See [1]. > I agree is seems logical to use POST - the actual URI being visited by the > user likely would be in the content body (although a request header similar > to Referer could be used) and no state from the server is being retrieved, > but it still bugs me. Maybe I'm just reacting to the (lack of) privacy > issue. > > > > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 > > Section 9.1.1 - "...allow the user to be aware of any actions they might > take which may have an unexpected significance..." > "...This allows user agents to represent other methods, such as POST, PUT > and DELETE, in a special way, so that the user is made aware of the fact > that a possibly unsafe action is being requested." > > Will the user-agent represent these links in a special way, so the user is > made aware of the fact that a possibly unsafe action is being requested? > > > > > > I would say it's OK to send a POST as a side effect because > > it's going to an URL where the developer expects a POST. > But that's not what the user clicking the link expects. > > > > If you can come up with a reason why it's not safe, I'd like to hear it. > My initial reaction was to be concerned about a malicious link that > triggered a POST for a resource that becomes modified or deleted - like > href="http://www.flickr.com/photos/dierken/?delete=39177102&magic_cookie=528 > 479cac210fc6z837c0ac708334fe6" (Those freaking blockheads at Flickr just > deleted my picture when I pasted that URI into the browser window. Losers - > when will they realize that an anchor is not a UI widget. Thank goodness > that I don't have a pre-fetch utility running or I'd lose all my vacation > photos.) > > But of course anybody that can cause that extra attribute to appear on an > anchor, likely has enough control to do some damage anyway. > > > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, On 10/21/05, S. Mike Dierken <[EMAIL PROTECTED]> wrote: > > > > Or is it just "hitting" -- making an hidden HTTP GET request of each > > > token in the "ping" attibute? > > > > Right. Hidden HTTP POST request, as it happens, but yes. > Oh, that really shouldn't be done via POST. Clicking a link should be safe > and sending a POST as a side-effect is not safe. Yeah, that's my thinking too. Perhaps we could use a totally new HTTP method for this (instead of "GET", "POST", or any of the other existing ones out there). Maybe "PING" See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, On 10/21/05, Ian Hickson <[EMAIL PROTECTED]> wrote: [...] > > Back to "feature detecting" though. Maybe if we had a kind of loopback > > "ping" that would work. (If that makes sense.) That way a document > > could initiate a "ping" to somewhere it would be able to detect. > > You can detect whether the UA supports it or not by putting the attribute > in uppercase: > >http://example.com"; PING="redirect?uri=http%3A%2F%2Fexample.com"> Is this proposal doing URI construction? I.e., taking what's in "href" and what's in "ping" and gluing them together? Or is it just "hitting" -- making an hidden HTTP GET request of each token in the "ping" attibute? I think the later would be more better. (At least from the point of view of someone writing advertising software.) So, I'd prefer something like: http://advertisers-site.dom/"; ping="http://advertising-network.dom/ping-me http://publishers-site.dom/ping-me";>click me So then when the user clicks on the link, the go to what's in the "href" -- to http://advertisers-site.dom/ . But the user's browser also "pings" -- makes an hidden HTTP GET -request - of the 2 URI's: http://advertising-network.dom/ping-me and http://publishers-site.dom/ping-me . See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg]
Hello, (Just thought I'd comment on this since I work in this industry.) For #2, I can tell you that advertising software will NOT use this unless they absolutely know it works. There'd need to be some way of detecting browsers that it works on. Without having to resort to browser detecting. Need to do "feature detecting". (I.e., don't want to have to check for specific versions of specific browsers. But want to check to see what "features" whatever browser they are on has.) For alot in the advertising industry, clicks are their "bread and butter". It's where the money comes from. They MUST be able to "record" a click. Also, it is often necessay to "ping" more than one URI. So you might want to make a system where you can list more than one URI. (Although I guess you could just have one "ping" URI and do redirect tricks with it.) Back to "feature detecting" though. Maybe if we had a kind of loopback "ping" that would work. (If that makes sense.) That way a document could initiate a "ping" to somewhere it would be able to detect. See ya On 10/21/05, Ian Hickson <[EMAIL PROTECTED]> wrote: > > One of the patterns I've seen a lot while looking at big sites is this: > > Foo > > ...where "redirect" is a CGI script that records that the user followed > the link, and that then redirects the user to the real page (potentially > setting a cookie in the process). > > This is used for four main reasons: > > 1. Improving sites, by getting data regarding how users use the site. > > 2. Keeping track of which adverts were clicked on, for book-keeping. > > 3. Improving services, e.g. by offering a number of options, checking > which the user picked, and making that one be the first on the list > the next time the user uses the service. > > 4. Uniquely identifying and tracking a user for evil purposes. > > Sometimes more than one of the above is done, e.g. clicking on adverts > sometimes informs the publisher and the advertiser before moving the user > to the real destination. > > The problem at the moment is that the redirect mechanism obscures the > eventual target URI. It would be good to have the target URI separate > from the tracking URIs, so that the UA can show each of them separately in > the UI, indicating the user who is getting told what. > > Doing this would also allow the UA to easily turn off the pinging thing > for users who are worried about point 4 above. > > Bearing the above in mind, I've added a section to the element that > describes a ping="" attribute. The URIs given in this attribute would be > followed when the user clicks the link, thus getting around the problems > listed above. > > Now, because of number 4 above, I'm guessing this is going to be > controversial, which is why I'm calling this out explicitly (as opposed to > waiting til I've filled in all the TBW sections and then just asking for a > general review, since people might miss it if I did that). > > Thoughts? Is it evil? > > http://whatwg.org/specs/web-apps/current-work/#ping > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
