Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
Considering internationalization: the alternative text should be translated to the language of the surrounding text, of course. I would recommend such a workaround only if some alternative text is required; see the OP. The point is that the browser tells the viewer that ho is missing some information that the designer considers important. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kornel Lesinski Sent: Sunday, April 22, 2007 9:18 PM To: Kristof Zelechovski Cc: whatwg Subject: Re: [whatwg] Alt text authoring Re: Conformance for Mail clients On Sun, 22 Apr 2007 18:58:13 +0100, Kristof Zelechovski [EMAIL PROTECTED] wrote: For (2): alt=(Your browser does not display graphic images). What's the point? Users who rely on alt attribute know that already, and unless exactly that phrase is required by the specification (= bad for i18n), it won't be any use for bots either. I think presence of the title attribute (which might be empty) could be required if alt is omitted: img title= src=canyon.jpg or maybe: img alt=- src=canyon.jpg and role of img src=canyon.jpg should be left undefined, allowing UAs to use heuristics to guess it. -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Apr 23, 2007, at 03:00, Andrew Sidwell wrote: Maciej Stachowiak wrote: How about: img src=gallery2.jpg alt= -- image could be omitted without changing the meaning of the document (screen readers or text-only browsers could just skip it) img src=gallery2.jpg noalt -- image cannot be omitted without changing the meaning, but no text equivalent is available (screen readers or text-only browsers / mail clients should give some indication that an image is there) I actively like noalt. I fail to see why noalt would better than the absence of the alt attribute. Web apps like Flickr could generate noalt with good confidence, but I don't see how quasi-WYSIWYG tools could be none the smarter with generating noalt than they could be with omitting alt. Therefore, I think the spec should cater for the behavior of Lynx here. Using alt= has always seemed like a hack to me, implying that it did have alternative text when really it didn't. Indeed. It is the obvious effect of trying to factor unrealistic ideals into conformance requirements. The harm-minimizing fix is to concede that you cannot force people to provide alt if they don't want to and make alt optional for the purposes of document conformance. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
It seems you should replace all embedded content images with links to download them as stand-alone resources if you want to be strictly conformant with the images are an alternative of text theory. I am not particularly happy with this method because I would have to use a graphic processor to add a caption to such an image. While it can be done using a script, even if the caption depends on the content language, it is a highly nonstandard trick. And you cannot easily copy such a caption as text without using OCR, which is also possible but equally uncommon and cumbersome. The alternative of embedding images as objects is unrealistic given Microsoft's current stance on the subject. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henri Sivonen Sent: Monday, April 23, 2007 11:44 AM To: Andrew Sidwell Cc: WHATWG List Subject: Re: [whatwg] Alt text authoring Re: Conformance for Mail clients Indeed. It is the obvious effect of trying to factor unrealistic ideals into conformance requirements. The harm-minimizing fix is to concede that you cannot force people to provide alt if they don't want to and make alt optional for the purposes of document conformance. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] Infinite loopcount for audio and video
Is there a way to specify continuous looping for audio and video elements? e.g. something like audio src=spacemusic.mp3 autoplay=autoplay loopcount=Inf / If not, should there be? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Infinite loopcount for audio and video
Makes sense to me. If such a thing is not already spoken for why not aim toward a little consistency with pre-existing implementations, like in SVG, where it would be repeatCount=indefinite? Not my favorite piece of nomenclature ever, but it's out there and has a user-base already. David - Original Message - From: Elliotte Harold [EMAIL PROTECTED] To: WHAT WG List [EMAIL PROTECTED] Sent: Monday, April 23, 2007 3:20 PM Subject: [whatwg] Infinite loopcount for audio and video Is there a way to specify continuous looping for audio and video elements? e.g. something like audio src=spacemusic.mp3 autoplay=autoplay loopcount=Inf / If not, should there be? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Infinite loopcount for audio and video
loopcount=forever? It looks better than Inf. loopcount=-1? Is a number, + a static constant for LOOPCOUNT_FOREVER in the DOM. Not that I consider the exact wording very important anyway. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ddailey Sent: Monday, April 23, 2007 9:33 PM To: Elliotte Harold; WHAT WG List Subject: Re: [whatwg] Infinite loopcount for audio and video Makes sense to me. If such a thing is not already spoken for why not aim toward a little consistency with pre-existing implementations, like in SVG, where it would be repeatCount=indefinite? Not my favorite piece of nomenclature ever, but it's out there and has a user-base already. David - Original Message - From: Elliotte Harold [EMAIL PROTECTED] To: WHAT WG List [EMAIL PROTECTED] Sent: Monday, April 23, 2007 3:20 PM Subject: [whatwg] Infinite loopcount for audio and video Is there a way to specify continuous looping for audio and video elements? e.g. something like audio src=spacemusic.mp3 autoplay=autoplay loopcount=Inf / If not, should there be? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] [WF2] button without value= should perhaps use .innerText as value
Simon Pieters wrote: On Sat, 14 Apr 2007 03:28:35 +0200, Kornel Lesinski [EMAIL PROTECTED] wrote: On Sat, 14 Apr 2007 02:10:07 +0100, Simon Pieters [EMAIL PROTECTED] wrote: We currently don't have interop with IE and other browsers with regards to what to send to the server as the value of button. IE always sends .innerText as value. IIRC it's innerHTML, but I can't verify it at the moment. Ah. Indeed, it is. Replace .innerText with .innerHTML in my proposal. Ugh, this seems very messy. I think Kornel said it quite well when he said that there isn't likely many pages out there that rely on IEs behavior because you might as well use input type=submit. I bet Hixie knows how many pages out there uses button, possibly even button without a type attribute? Is there really a noticable number of sites that rely on IE's broken behaviour? Apparently, enough for the IE team to not change it for IE7, despite me sending a bug report about it. (The bug was closed as by design IIRC.) This is a poor test since Microsoft is very conservative with regards to chaining behavior. See recent threads on the HTML WG list. From what I understand they aren't going to change behavior unless it can be proven that no sites will break. I prefer to go the other way and say that we should do what makes a good spec unless it can be proven to break sites (as a general rule of thumb). / Jonas
[whatwg] meter: long vs. float
I'm probably missing something obvious because I'm not a DOM expert.
However when reviewing the meter element I note the following:
interface HTMLMeterElement : HTMLElement {
attribute long value;
attribute long min;
attribute long max;
attribute long low;
attribute long high;
attribute long optimum;
};
However, User agents must parse the min, max, value, low, high, and
optimum attributes using the rules for parsing floating point number
values.
Is long in fact the appropriate type for something that's parsed as a
floating point number? Should it be double or float or real or some such?
--
Elliotte Rusty Harold [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Infinite loopcount for audio and video
The marquee element uses the loop attribute: http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/loop_1.asp where -1 means that it loops infinitely. Personally, I prefer that one the most. Regards, Martijn 2007/4/23, Stefan Haustein [EMAIL PROTECTED]: Hi, I think in loopcount=forever the units do not match (no unit / time). I would prefer Infinity because it is a valid ECMAScript literal (=1/0). Indefinite (=0/0 ?) looks really strange... Best regards, Stefan Kristof Zelechovski wrote: loopcount=forever? It looks better than Inf. loopcount=-1? Is a number, + a static constant for LOOPCOUNT_FOREVER in the DOM. Not that I consider the exact wording very important anyway. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ddailey Sent: Monday, April 23, 2007 9:33 PM To: Elliotte Harold; WHAT WG List Subject: Re: [whatwg] Infinite loopcount for audio and video Makes sense to me. If such a thing is not already spoken for why not aim toward a little consistency with pre-existing implementations, like in SVG, where it would be repeatCount=indefinite? Not my favorite piece of nomenclature ever, but it's out there and has a user-base already. David - Original Message - From: Elliotte Harold [EMAIL PROTECTED] To: WHAT WG List [EMAIL PROTECTED] Sent: Monday, April 23, 2007 3:20 PM Subject: [whatwg] Infinite loopcount for audio and video Is there a way to specify continuous looping for audio and video elements? e.g. something like audio src=spacemusic.mp3 autoplay=autoplay loopcount=Inf / If not, should there be? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
[whatwg] include element
Hi All,
This is an idea I have had floating around in my head for a while and
a recent couple of threads reminded me I really need to post it here.
Basic idea:
The idea is basically an element like iframe but that renders the
linked page, instead of inside a square area, in flow with the main
page. This idea is really rough still, but I hope to try to implement it
in a not too distant future to solidify it a bit. One thing very much up
in the air is what the element would be called. Suggestions welcome, but
I'm using the name include below.
Examples:
Example 1.
Something like http://google.com/suggest could easily be built using
markup like this:
input oninput=dropdown.src = urihead + this.valuebr
div style=position:absolute;
include id=dropdown/include
/div
script
var dropdown = document.getElementById('dropdown');
var urihead =
http://www.google.com/complete/search?hl=enclient=suggestjs=truequ=;
/script
The document contained at the search uri would then simply contain a
list of the result in the form of:
html
body
p
hello worldbr
foo barbr
...
/p
/body
/html
The first nice thing to note in this is that it requires very little
javascript on the part of the web author. Currently a lot more code is
written to set up an XMLHttpRequest, send a request and insert the
response into the rendered page.
Another nice thing is that the result can stream in. Even when just half
of the response is downloaded the UA can still render what is available.
You'd obviously need more code to deal with the user navigating into the
suggested results list, but that is needed anyway.
Example 2.
Similarly, the listing of a emails in a mailbox could be done using
something like this:
div onclick=mailbox.src = urihead + event.target.textContent + '#b'
divinbox/div
divjunk/div
divdrafts/div
divwork/div
/div
...
table
tr
thSubject/th
thFrom/th
thDate/th
/tr
include id=mailbox/include
tr
td rowspan=3(c) Example Inc./td
/tr
/table
The returned page would contain the following markup:
html
body
table
tbody id=b
tr
tdHow's it going/td
tdTed/td
td2pm/td
/tr
tr
tdWhere're your taxes?/td
tdIRS/td
tdYesterday 8am/td
/tr
...
This uses the ability to specify a fragment identifier in the uri to
render just that element and its content.
Another thing to note is that the include element has to be allowed to
be parsed as a child of table.
API:
The API and behavior from a scripting point of view of an include
would be exactly that of iframe. There would be an inner document
accessible through a .contentDocument property. This document would have
a full window object and script context. Scripts in the document would
execute just like for an iframe.
Security Concerns:
The first limitation this tag has to have is that it'll be limited to
same origin uris. Otherwise it would be possible to extract data from
another site by setting fragment identifier uris and measuring the
resulting size.
One unsolved problem is that sites currently use blacklists to block
tags like iframe. However this problem is mitigated by the fact by the
same origin policy.
We might be forced to either use an opt-in mechanism in the header to
allow include (which would suck a lot), or we could reuse the iframe
element and add an attribute to indicate the new rendering model (which
would suck slightly less).
Open Issues:
Should the stylesheets of the outer or the inner document be used?
When a fragment identifier is specified, should we render that element,
or its children?
Should style be inherited from the parent of the include, or from the
DOM parent in the inner document?
Should the inner DOM be rendered inside of, or in place of the include?
All above could potentially be configurable by the author using
attributes on the include.
The following will probably not work:
selectinclude src=... //select
HTML5 has a solution for that though, so I think it's fine.
Best Regards,
/ Jonas
Re: [whatwg] include element
Jonas Sicking wrote: Basic idea: The idea is basically an element like iframe but that renders the linked page, instead of inside a square area, in flow with the main page. This idea is really rough still, but I hope to try to implement it in a not too distant future to solidify it a bit. One thing very much up in the air is what the element would be called. Suggestions welcome, but I'm using the name include below. If I understand what you are suggesting correctly, then we've been on the verge of implementing this (highly useful) behaviour for iframe for quite a while now: https://bugzilla.mozilla.org/show_bug.cgi?id=80713 Gerv
Re: [whatwg] Now there is table-element with predetermined quantity of column.But sometimes we need to visualize three tables(for example, database tables) as one table:first table contains names of r
Sorry, this went to the wrong list. Please ignore this one and follow the thread in the HTML WG instead. / Jonas Jonas Sicking wrote: Woha, please put the subject in the subject field, not the full proposal. Anyway, I agree with Preston, making 3 roundtrips to the server seems quite suboptimal. I would would instead try to integrate the data attribute from datalist and select elements. Microsoft has some stuff that deals with streaming data into tables (and I'll make a post in a second regarding a related idea I have). You should take a look at that. Best Regards, Jonas Sicking Dmitry Turin wrote: Now there is table-element with predetermined quantity of column. But sometimes we need to visualize three tables (for example, database tables) as one table: first table contains names of rows, second table contains names of columns (this table determine quantity of columns), third table contains data. I offer new html-element table3 for that: table3 rows=r.htm col=c.htm data=d.htm table3 rows=/cgi-bin/a.cgi?q=r col=/cgi-bin/a.cgi?q=c data=/cgi-bin/a.cgi?q=d Content of r.htm: th id=1RowName1/th th id=2RowName2/th th id=3RowName3/th Content of c.htm: th id=10ColName1/th th id=20ColName2/th th id=30ColName3/th Content of d.htm: td row=1 col=10Data11/td td row=1 col=20Data12/td td row=1 col=30Data13/td td row=2 col=10Data21/td td row=2 col=20Data22/td td row=2 col=30Data23/td td row=3 col=10Data31/td td row=3 col=20Data32/td td row=3 col=30Data33/td If some row or column don't exist for cell of data, then cell of data is throwed out. --- P.S. Requests in database for r.htm and c.htm: select 'th id=' + field_id + '' + field_name + '/th' from ... Request for d.htm: select 'td row=' + field_i + ' col=' + field_j + '' + field_data + '/td' from ... Dmitry Turin http://html60.chat.ru http://sql40.chat.ru
Re: [whatwg] Infinite loopcount for audio and video
I would do it this way: loopcount: -1 = Play once, and loop forever. 0 = Play once, but don't loop at all. (Default) 1 = Play once and then loop once. n = Play once and then loop n times. less than -1 or invalid or out of range = Use default of 0. -- Michael
Re: [whatwg] include element
Gervase Markham wrote: Jonas Sicking wrote: Basic idea: The idea is basically an element like iframe but that renders the linked page, instead of inside a square area, in flow with the main page. This idea is really rough still, but I hope to try to implement it in a not too distant future to solidify it a bit. One thing very much up in the air is what the element would be called. Suggestions welcome, but I'm using the name include below. If I understand what you are suggesting correctly, then we've been on the verge of implementing this (highly useful) behaviour for iframe for quite a while now: https://bugzilla.mozilla.org/show_bug.cgi?id=80713 Gerv Sounds like you're both reinventing XInclude. :-) -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] include element
Gervase Markham wrote: Jonas Sicking wrote: Basic idea: The idea is basically an element like iframe but that renders the linked page, instead of inside a square area, in flow with the main page. This idea is really rough still, but I hope to try to implement it in a not too distant future to solidify it a bit. One thing very much up in the air is what the element would be called. Suggestions welcome, but I'm using the name include below. If I understand what you are suggesting correctly, then we've been on the verge of implementing this (highly useful) behaviour for iframe for quite a while now: https://bugzilla.mozilla.org/show_bug.cgi?id=80713 There's a big difference to that and to what I'm proposing. With what's in bug 80713 you're still limited to a box that basically doesn't take part of the outer page at all. For example in the table example in my original post the headers of the table would not resize to fit the column sizes in the includeed table. / Jonas
Re: [whatwg] Web Documents off the Web (was Web Archives)
Tyler Keating wrote: On 16-Apr-07, at 3:03 PM, Maciej Stachowiak wrote: On Apr 16, 2007, at 1:39 PM, Tyler Keating wrote: Hi, I'm bringing this up again with a different tact, because the more that I think about it, the more I believe it has the ability to significantly change the perception and application of HTML and I would really like to keep the discussion alive. In the previous thread, I proposed a standard for archiving web sites into a single ZIP archive with a unique file extension and although it didn't get any outright negative feedback, it didn't drum up too much excitement either. If you can bear with me, I'd like to describe the idea again in a slightly different light. A cross-browser web archive format sounds like a useful thing. However, I don't think it should be part of or even tied to the HTML spec. In principle, such an archive could contain any browser-viewable content as the root document. This could be HTML, XHTML, SVG, generic XML, plain text, a raster image, or any number of other things. So such an archive format is logically a separate layer and should be specced as such. Okay. I understand it now... Thank you, you are right. Before I get out of here, whom do I bring this to instead? I'm guessing it needs to be the W3C Web Application Formats WG, but I'd like validation before I start bugging them (if that's even possible). I think this would be a good list, it just wouldn't be part of the webapps (html5) spec, but it would be a new whatwg spec. I think a lot of work has been done in this area though, so you should research what's out there. We talked a bit about this for firefox 3, but I'm not sure what the latest word is with regards to if it's still in the plan or not. Apples and operas widget formats would be a place to start looking. I think IE had some format as well. I know there are other things out there as well, but I can't remember them off the top of my head. In any event, like Maciej, I think it would be great to have a cross browser format for this stuff. / Jonas
Re: [whatwg] include element
On Mon, 23 Apr 2007 23:19:49 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: This is an idea I have had floating around in my head for a while and a recent couple of threads reminded me I really need to post it here. Basic idea: The idea is basically an element like iframe but that renders the linked page Something similar has been proposed recently: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010801.html IMHO such includes don't solve the biggest problem of frames - that there's only a single usable URL and all actual content is in orphaned scraps of documents. Your use-case is a bit different, but I think such include will be commonly abused as a drop-in replacement for iframe. I suggest investigating further concept of ID overlays instead: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010805.html -- regards, Kornel Lesiński
Re: [whatwg] Web Documents off the Web (was Web Archives)
At 15:45 -0700 23/04/07, Jonas Sicking wrote: In any event, like Maciej, I think it would be great to have a cross browser format for this stuff. Yes. But to be clear, I think widgets and web archives are or may be slightly different. A widget package is a distribution package, I think. A web archive is trying to say this is what you would have experienced (or did experience) when you accessed this. This might involve capturing 'transient' information, such as URLs, and information in or derived from HTTP headers etc. I'm the editor of the media file format specs at MPEG and help at 3G etc. The base file format on which MP4 and 3G and 3G2 are based recently introduced a packaging ability, where each item can be separately stored, named, protected, compressed (or even located outside the main file defining the package). It also identifies one of the items as the primary one (the main entry point), which I know has been an issue with 'folder' formats like ZIP etc. I could say more if people are interested. -- David Singer Apple Computer/QuickTime
Re: [whatwg] Web Documents off the Web (was Web Archives)
Dave Singer wrote: At 15:45 -0700 23/04/07, Jonas Sicking wrote: In any event, like Maciej, I think it would be great to have a cross browser format for this stuff. Yes. But to be clear, I think widgets and web archives are or may be slightly different. A widget package is a distribution package, I think. Hmm.. the difference is quite small. Would there really be any difference if you added meta information about what URI and maybe what timestamps the files were fetched at to the widget distribution format? I guess the implementation could be quite different. One way of doing archiving would be to store all files exactly as they came from the wire in a container (zip), and then include information that map uri to filename. Whereas if you were to use the widget format you would be required to modify the downloaded files so that external references pointed directly to the other files in the container. / Jonas
[whatwg] embed height width DOM attributes
They should say something different from what the img element says. ;-) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
