Re: [whatwg] [wf2] Leap seconds, dates in the past
On Wed, 16 Aug 2006 05:33:26 +0200, mozer [EMAIL PROTECTED] wrote: A lot of work as already been done by the W3C XSL WG on calendar (and even negative year in needed) http://www.w3.org/TR/xslt20/#lang-cal-country On 8/15/06, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 10 Apr 2006, Michel Fortin wrote: I'm inclined to think that the best option for WF 2.0 is to require the use of the proleptic Gregorian calendar all the way to 0001-01-01. What about prior dates? I don't think we need to support years before 1CE. ... Anybody doing real work with dates that far back is going to have very specific needs when it comes to calendars and WF2 isn't going to cut it for them. I disagree. There are a lot of use cases for simple forms dealing with dates before 0001-01-01 even if we just use the proleptic Gregorian calendar. The most obvious is a conversion widget between calendars - there is no need for machine-interpretable information to know that one date is julian and one gregorian to find the right dates for tracking key events leading to the October Revolution... I think it is a reasonable decision to simply use proleptic Gregorian as the default date type, although I would like to see WF3 have some mechanism to declare a variation from that, because there are use cases where that is necessary for things that will happen in the next few months... If the goal of WF2 is to provide something simple for people to use, then it ought to be a preferable option for people like history teachers with basic web skills, or the support guy or smart kid at school who helps them out. -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Dynamic content accessibility in HTML today
On Mon, 14 Aug 2006 15:48:06 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 14 Aug 2006 06:36:40 -0700, James Graham [EMAIL PROTECTED] wrote: But XBL works with ~0 assistive technologies and is presumably going to be complex to implement properly. Whilst, in general, I agree that having elements used in the correct way to provide semantic information is desirable, I think that adopting a technology that is already implemented and proven to solve real problems is a better approach than waiting on a complex future specification to be finished and implemented. So a while ago I posted http://annevankesteren.nl/2006/06/accessibility-ideas some of my thoughts regarding role=... Basically, I don't really see authors taking extra steps to make things accessible. Accessibility should just be an integral part of the language, otherwise I don't think it will work. For authors it will seem that without role= their custom widgets will work so there's no real benefit in adding it unless you work for some big company that hires a few accessibility experts who tell you to add it. This was the argument used throughout the 90s against the alt attribute. (There are better arguments, like even if you do use it the design is crap but they weren't really the major issue then). It turns out that bit by bit people learn to get it. Alt attributes are used a lot more than they were, and better. (Yes, this means that they are now used infrequently and badly. But that's a big practical improvement). Making accessibility part of the language is a good idea. But it is no better in practice than role, since people don't use the semantics consistently and make a big effort to innovate using JS and so on. The role attribute won't be perfect but it gives people a relatively reliable way to add something that won't impact on the rest of what they do (when alt got overloaded for tooltip this became a problem). There are also ways to add it post-hoc, e.g. by browserJS or something similar. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] input type=country?
On Thu, 24 Aug 2006 18:44:26 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: I agree with all the arguments against speccing this, but also this smells much more like a browser feature to me. I think a much more realistic approach would be for browser vendors to offer a setting to try to by default select the user's country when they encounter such a list in a page's form. Agreed. A good implementation would - know how to handle different spellings/synonyms (like US/USA, UK/England, Holland/The Netherlands/Nederland, etc.) - make proper use of the OS' language/location settings, if available, for its initial setting, but allow the user to override that (because, for example, many run their OS in american english even though their location or nationality may be something else.) Some people will probably argue that users won't bother to define their settings for this, but IMO that only means that the user apparently doesn't care then. Right. Or is like me and selects too many countries for too many different things to have a sensible default. I imagine the quickest way to get an implementation would be in the form of a Firefox plug-in. Actually, it should be possible as a user javascript, for anyone who can write javascript right. find select where option=$Locale remove selected from option selected in that select. Set option=$locale selected. or something like that. Hi Sander, BTW. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Dynamic content accessibility in HTML today
On Thu, 24 Aug 2006 19:36:53 +0200, James Graham [EMAIL PROTECTED] wrote: Matthew Raymond wrote: So [snip]ping lots of stuff that is kinda interesting but not in a very relevant way. The language of the |role| specification is actually unclear. The intro indicates that |role| can be used to describe the semantic meaning of elements, while Section 3 says the following: It is used by applications and assistive technologies to determine the purpose of UI widgets. OK, I think I hadn't appreciated just how vague the W3C document is. I propose we standardise the following: A role attribute which may appear on (only non-semantic?) elements to indicate that that element is part of a DHTML widget and not marked-up prose. The role attribute would not be namespaced (in HTML5, in XHTML5... well who knows). The role attribute would take certain predefined values (not those on the W3C page which are largely useless, e.g. banner, or otherwise covered in HTML5, e.g. navlist) corresponding to the various types of UI widgets understood by the accessibility toolkits. As far as possible we would stick to whatever Firefox currently implements, but we would simplify the syntax where necessary (e.g. avoid qnames wherever possible). Values outside the predefined list would make the document non-conforming. Does that sound reasonable or have I totally missed the point? About right except there is a mechanism in the W3C work for adding new values, which don't make it non-conforming. Given that people are pretty inventive, I think that is quite valuable. YMMV And it can appear on any element, although there is not much point adding it to things that use well-defined semantics already. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Dynamic content accessibility in HTML today
On Thu, 24 Aug 2006 20:16:14 +0200, James Graham [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: About right except there is a mechanism in the W3C work for adding new values, which don't make it non-conforming. Given that people are pretty inventive, I think that is quite valuable. YMMV I don't see the point; if someone makes a value up and UAs don't support it then it is worthless, if UAs do support it then it should become part of the next HTML spec. I can't imagine how auto-discovery of new widget types would work (maybe I should read the RDF Taxonomy spec but I can't stomach it), Yes, if you want to know how this is expected to work I guess you should. The benefit is that it might be 8 months between new specs, and 8 days between new inventions and people suffering because they have no way to use them, and an auto-discovery mechanism that doesn't always rely on writing a new spec would be an improvement on that. and I can't think of any similar auto-discovery technology that is widely by authors. I guess allowing a predefined list of values and vendor extensions like role=ms-ribbon might be a suitable compromise between innovation and ease of use. The RDF solution at least provides for a workable auto-discovery mechanism. Which means that vendors don't just spend their time chasing down other vendors' extensions manually. I'm not sure that the gap between the two is worthwhile. In principle I would rather see things invalid than magic lists. In practice I suspecting I am making water towards the oncoming wind - vendors would do it anyway - which is why I support the RDF thing. (Plus I am one of those people who can write RDF easily, or find a tool to do it for me, but cannot stomach anything that says first just write a script...) Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] return lowercase hex values for fillStyle and strokeStyle
On Tue, 05 Sep 2006 19:07:35 +0200, Nicholas Shanks [EMAIL PROTECTED] wrote: On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote: Instead of returning an uppercase six digit hex value I suggest returning a lowercase value for compatibility with what UAs (including IE) currently do It may be the right decision on compatibility grounds, but other than that lowercase hexadecimal digits (0-9, a-f) are almost always a bad choice, because a, c and e have no ascenders like every hindu-arabic decimal digit has and thus make the number harder to read. This obviously does not apply to fonts with old-style numerals aka. text figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to be used in a programming environment. I believe this, but I suspect that the gain in compatibility is well worth the minor loss in efficiency for people who are hand-coding. I disagree, and always prefer uppercase hex digits to lowercase ones, it makes the numbers easier to read IMO. That is, I think, what Christopher said and I agreed with. I still think that compatibility with deployed browsers should, in this case, trump that usability gain. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Modal Dialog Box support
On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond [EMAIL PROTECTED] wrote: Rimantas Liubertas wrote: [Snip!] Chapter 30 Using Dialogs in About the Face 2.0 [1] by Alan Cooper makes a good read too. [1] http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8s=books So, what, we're supposed to order and read a book from Amazon.com in order to know what you're talking about? You could always go to a library. I believe the reference was offered as something useful, should you be inclined to take the time. Cheers -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
[whatwg] Books and rhetoric Re: Modal Dialog Box support
On Wed, 06 Sep 2006 20:46:52 +0200, Matthew Raymond [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: So, what, we're supposed to order and read a book from Amazon.com in order to know what you're talking about? You could always go to a library. I believe the reference was offered as something useful, should you be inclined to take the time. Sorry if I was impolite. It was not my intention, but in any case I will make a bigger effort to be tactful. 1) Not everyone lives near a public library with a wide selection of computer science books. Quite. Some people also have the luxury of a public library system that will if necessary ship books loaned from other libraries (librarians worked pretty hard to make systems like this work. t is a shame if people no longer realise what they have...). 2) Not everyone has the time and the gasoline (which is expensive these days) to go to the library every time someone references a book on a mailing list. Naturally. The same as your point that not everyone can buy the book and read it. 3) Response to the email in question is delayed while the reader is hunting for a book. Of course, if the discussion is based on the book to the extent that it is necessary to read it in order to take further part. (There are cases where that is justifiable, of course. Discussing the details of a piece of research without having read it is a bit pointless...) James Graham was more tactful about this, and I suppose I could have myself been a little more tactful to the person who posted the Amazon.com link, but I want it to be clear that it's not acceptable for someone to have to be well read to participate in this mailing list. As such, your comment may be seen by some as elitist. something useful, should you be inclined to take the time was meant to imply that it is not essential, but those who want to become ridiculously well-read™ might find it interesting. My impression was that reading this book was not core to understanding the statement, just that it laid out what is presumably a similar argument in more detail. Reductio ad absurdum (what you did, taking my argument to its logical extreme to show that it is of limited value) cuts both ways. There is no requirement that people know anything at all about the Web to participate on this list, although it would be a waste of almost everyone's time. It strikes me as pretty obvious that being well read will increase the value of your contribution, and probably what you gain from this list as well. That does not mean you should read every book somone names, but nor should you expect people to restrict their statements to things that do not rely on any research that is only published in a form that requires payment (although good manners is, as James suggested, to at least summarise such information here for those who don't have a limitless book-buying budget and the spare time to sit and read every stray scrap that passes by). I am quite content to be accused of saying that people who know more can better contribute. I do not at all subscribe to the idea that you must be ridiculously well-read™ to participate, nor do you have to be so to have very valuable contributions to make. (Some people will criticise me whatever I say. Others will always agree and praise it. For the most part, neither of these groups are very interesting). Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Tim BL's HTML WG announcement and WHAT WG
On Mon, 30 Oct 2006 14:04:46 +1000, J. King [EMAIL PROTECTED] wrote: On Sun, 29 Oct 2006 12:16:44 -0500, Charles McCathieNevile [EMAIL PROTECTED] wrote: There was at least one major issue in WF2 that came out from actually *implementing*. What was the problem? Default values for forms that were invalid. cheers -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Tim BL's HTML WG announcement and WHAT WG
On Mon, 30 Oct 2006 19:56:19 +1000, Henri Sivonen [EMAIL PROTECTED] wrote: On Oct 29, 2006, at 19:16, Charles McCathieNevile wrote: So what comes out will probably be a (perhaps evolved) version of WHATWG stuff, as has been the case in some other W3C groups already. That would be excellent. Perhaps I was overly worried, because I couldn't tell from the announcement where this is going. I hope so :) Or will the WHAT WG activities continue with an endorsement from the W3C? I would be very surprised. As Tim notes, the WHATWG doesn't have what he calls accountability measures (by which I think he means a process with more of the checks and balances that are found in W3C's), which would make it hard for W3C to endorse anything WHATWG have yet to do. I don't expect the W3C to endorse the WHAT WG itself. What I meant to ask if the WHAT WG spec drafts continue to be worked on under the banner of the W3C. This is an existing trend so I don't see why it wouldn't continue... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Graceful Degradation and Mime Types[was: trailing slash]
On Wed, 06 Dec 2006 07:52:17 +0530, Karl Dubost [EMAIL PROTECTED] wrote: Le 6 déc. 2006 à 04:08, Martin Atkins a écrit : Mike Schinkel wrote: All really sucessful text formats have been easy to edit (why did RSS take off while RDF is still struggling to get off the ground?) I don't necessarily disagree with your sentiment, but it could be argued that RSS has done well while RDF has floundered largely because RSS solves a real-world problem (how to get news/weblog content into aggregators) while RDF solves a purely theoretical problem that less people have a pressing need to solve (A generic representation of relationships between resources). just for the record and if you really want to compare things. RSS 2.0 is an application of XML RSS 1.0 is an application of RDF/XML I would characterise it differently. Every wo/man and their blog uses (some half-arsed borken form of) RSS because it solves trivial little problems that are faced by zillions of people. RDF has a smaller usage base, because the problem it solves is interesting to a smaller group. That said, the more complex problem is where a lot of money is being spent, and there is significant interest in it from people who are building businesses beyond the small web-design shop. To say it is foundering seems to me like suggesting that jet aircraft are foundering because most people use propellor planes, or cars. cheers -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
[whatwg] finding a number...
Hi guys, why does finding a number in text [1] insist on . as a decimal seperator, when , is also very commonly used? [1] http://www.whatwg.org/specs/web-apps/current-work/#steps cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] finding a number...
On Wed, 13 Dec 2006 01:51:32 +0530, Henri Sivonen [EMAIL PROTECTED] wrote: On Dec 12, 2006, at 15:36, Anne van Kesteren wrote: On Tue, 12 Dec 2006 14:31:23 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: why does finding a number in text [1] insist on . as a decimal seperator, when , is also very commonly used? I think the format should be kept simple (and potentially politically incorrect), because the human-readability is only a legacy fallback issue. That is, users aren't exposed to the number formatting in UAs that actually implement progress bars and gauges. You might also want to use this algorithm for the proposed class=price. In that case you really want to take into account , as well. What would 2,500 mean? Would it mean two and a half or two-thousand- five-hundred? In english it generally means two thousand five hundred. In french, it invariably means two and a half, to an accuracy of one in a thousand. How can this be dealt with without making the parsing dependent on lang and requiring the UAs to implement all-encompassing CLDR-aware number parsing? It can't. But why bother making a standard that so clearly fails to work in major world languages? Everything should be as simple as possible *and no simpler* - this is too simple. Maybe assuming you can parse numbers out of text is just a dumb idea as a normative part of a spec. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] finding a number...
On Wed, 13 Dec 2006 13:17:14 +0530, Henri Sivonen [EMAIL PROTECTED] wrote: On Dec 13, 2006, at 08:32, Charles McCathieNevile wrote: How can this be dealt with without making the parsing dependent on lang and requiring the UAs to implement all-encompassing CLDR-aware number parsing? It can't. But why bother making a standard that so clearly fails to work in major world languages? Everything should be as simple as possible *and no simpler* - this is too simple. Maybe assuming you can parse numbers out of text is just a dumb idea as a normative part of a spec. The attributes always work for any language. For English, the textContent works as a *bonus*. It isn't that the spec fails to work for non-English. It is just that a particular *redundant* bonus feature doesn't work for non-English. The problem with this is that it means copying code the natural way doesn't work for some non-english speakers, and they have to read the spec or guess why. And that you therefore aren't really handling the Web as people actually write it, just some part of it If giving redundant bonus features to English-language pages is deemed politically too incorrect, I'd rather get rid of the textContent stuff than introduce the huge can of worms language-dependent number parsing. Up to you guys... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] finding a number...
On Wed, 13 Dec 2006 19:43:10 +0530, Mikko Rantalainen [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: On Wed, 13 Dec 2006 13:17:14 +0530, Henri Sivonen [EMAIL PROTECTED] wrote: On Dec 13, 2006, at 08:32, Charles McCathieNevile wrote: possible *and no simpler* - this is too simple. Maybe assuming you can parse numbers out of text is just a dumb idea as a normative part of a spec. The attributes always work for any language. For English, the textContent works as a *bonus*. It isn't that the spec fails to work for non-English. It is just that a particular *redundant* bonus feature doesn't work for non-English. The problem with this is that it means copying code the natural way doesn't work for some non-english speakers, and they have to read the spec or guess why. [...] I think that they have to read the spec is a bonus, too. Yeah, except it turns out to be wishful thinking of the kind WHATWG tries strenuously to avoid :( And where the problem is that people who habitually use conventions for numbers, it turns out that many of them don't really read english documents or mailing lists either... Perhaps the parser could be specified as follows: regexp for numeric value is [0-9 ,.] scan the numeric value backwards from end first character matching regexp [,.] is the decimal separator This would correctly interpret numbers such as 1,251,152.124 634.46 453.436.346,235 This last is the important use case that the existing method fails. 23 236 435 123,121 It would fail for numbers such as 1,234,456.789,012 1.234.456,789.012 but that such formats used in any locale? Not that I know of. Formats I know of use ., , or as seperators for integer amounts, and , or . for decimal seperators. The only seperators I know of inside the decimal part are -, e and E. I can imagine someone using the notation for web content in a meter, but I am not sure that it is likely. Of course there are a handful of other types of numbers. One thing that is helpful is that in hebrew and arabic, numbers are written LTR even though the rest of the text isn't. I am not sure about other LTR languages - apparently there are a couple of Indic ones. On the other hand, since I am going to meet a handful of people this weekend who specialise in publishing for the Indian government, in at least their 22 constitutionally official languages, I will try to remember to ask. One thing that is unhelpful is that in some languages numbers are written using ordinary letters. Although I suspect this use is very rare on the web, as I believe it is pretty much archaic in the relevant languages. This is, of course, going down the path of specifying internationalised number picking - something that some people are ust dead against. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] [WebApps] canvas transform()/setTransform()
On Thu, 28 Dec 2006 03:02:05 +0100, 黒澤剛志(KUROSAWA, Takeshi) [EMAIL PROTECTED] wrote: Dear WHATWG, Web Application 1.0 adds the transform() and the setTransform() to the canvas 2d context. The conversion of the arguments of these methods to the matrices is described in the section 3.14.6.1.2. The transform(m11, m12, m21, m22, dx, dy) method must multiply the current transformation matrix with the matrix described by: m11 m12 dx m21 m22 dy 0 0 1 The setTransform(m11, m12, m21, m22, dx, dy) method... - http://www.whatwg.org/specs/web-apps/current-work/#transform ...the matrix should be m11 m21 dx m12 m22 dy ... (b) 0 0 1 In particular, this would make for easy compatibility with SVG transformations, helping authors to copy them from one to hte other format and back. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] blockquote cite and q cite
On Sat, 06 Jan 2007 04:13:54 +0100, Karl Dubost [EMAIL PROTECTED] wrote: Le 5 janv. 2007 à 20:12, James Graham a écrit : That timing assumes that I have the book that I am quoting from open on the desk in front of me. It is just as likely that I am quoting from notes I made e.g. for the case of a reference book in a library (in which case I could write down the ISBN, if one exists, but would haveto do so in addition to writing down human friendly metadata like, say,the book's title and author which I could use to make sense of mynotes), that I'm quoting from memory, that I'm repeating a quote from a secondary source (e.g. looking up a quote from /Hamlet/ in a book of Shakespeare criticism because it is easier to find), quoting from abook without an ISBN or doing number of other things which prevent theISBN from being close at hand. Interesting because I do read a lot, I do write quotes a lot in my paper notebook and one thing I do for every quotes I put is - title, author, isbn and page number. why? because there are many editions of the same book, and if you wantto find the reference in the physical object you will need the isbn(even if sometimes this one is unstable as well. rare case) ISBN is nice, if you happen to have it handy and know it. But there are probably as many quotes from the Bible as from most sources, and people tend to quote chapter and verse which is actually an extremely useful reference - much more so than the ISBN for a particular edition. It's a typical metadata/semweb scenario. You have some kind of useful data, but different people have different kinds and relying on one particular version fails as many people as it helps. (I like RDF because it was designed to provide useful answers in the face of lots of partial information). Having written a lot of stuff in the traditional academic world that is slowly crawling to the Web, I don't see a lot of ISBN references. And because of my field, perhaps, they are really not useful - a text might have a dozen completely different editions in a single language, but has an internal structure that is well-known and makes it easy to find. In the world of printed media ISSN and ISBN are something akin to browser-specific hacks to find something. Useful in theory, but not a good basis for any serious work directed at the people who are actually going to read what you wrote. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] [WebApps] canvas transform()/setTransform()
On Wed, 17 Jan 2007 01:37:45 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 28 Dec 2006, ��߷���(KUROSAWA, Takeshi) wrote: ... the matrix should be m11 m21 dx m12 m22 dy ... (b) 0 0 1 I have fixed the spec as you request. Sorry for the delay in responding. Thanks Ian, cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element
I fail to see how this is different from an em element... (very loose and abused semantics, but I dont see how adding a new element to mess up is helpful) my 2 cents chaals On Mon, 05 Feb 2007 01:19:56 +0100, Sarven Capadisli [EMAIL PROTECTED] wrote: re: http://www.whatwg.org/specs/web-apps/current-work/#the-m Following is a conversation from #whatwg on freenode. csarven if anyone would like to explain the `m` element further, i'd appreciate it. couldn't get much info out of the whatwg Archives zcorpan you use it to mark text csarven 'mark' as in making the location of the content more significant then the rest? zcorpan not sure what you mean with the location csarven where the mentioned text is in the document. csarven to me it seems to be more of a presentational issue then having a semantic meaning behind it zcorpan there may be different reasons behind why you want to mark or highlight a piece of text csarven for instance? zcorpan one reason might be to highlight search terms, another may be to mark errors in the document, or things you should remember specifically csarven in those cases the marked text has no extra meaning other then how it would be viewed or interpreted. highlighting does not change the reading of the text when you're reading straight through, it just helps you find the bits you should pay attention to. - http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-May/003946.html csarven in that sense, why not `span` with a class? csarven im trying to understand this better (not arguing with you) zcorpan span with a class is longer to type csarven that i can't argue mpt Like on those pissantly annoying Welcome Google user! You searched for xyz pages, where xyz is highlighted csarven the 'text' though has no extra meaning. `m` seems to handle a presentational issue. like i was wondering, why not `span` with a class which can cover numerous cases similar to highlighting zcorpan i don't think highlighting is presentational csarven how should `m` be treated under Lynx? zcorpan it could have a different text color and you could have a shortcut key to jump to the next m element csarven as opposed to a predefined class name 'marked' that does just that? zcorpan i don't think m is any better than span class=marked except that the former is shorter csarven but thats introducing a new element for a very narrow usage especially where it has no extra meaning. given the idea that the reading of the marked text is no different then any other text on the page, i fail to see why a new element is necessary where `span` with a class can handle this scenario. i also can't come to terms with a new element being introduced because `span` with a class is too long in comparison to `m`. -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element
On Wed, 07 Feb 2007 01:25:37 +0530, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Tue, 06 Feb 2007 09:13:27 +0100, Mikko Rantalainen [EMAIL PROTECTED] wrote: Perhaps m should be considered as a special case of em. I would have to agree that semantic value of m over em is next to meaningless. I think that one usable definition between m and em would be that m is meant for highlighting content for a single user and em is meant for emphasizing stuff in general. That would limit usage of m to dynamically generated content only, though, and reserving such a short tag for that purpose only doesn't seem reasonable. IMO, the key difference between m and em is that m is intended to be placed by somebody or something other than the author of the original text. HTML doesn't really imply that an original author or later editor decided on what markup to use. Highlighting search hits is one of the examples (the hits are marked by the search engine, not by the author of the text). Another example can be quoting someone and using m to mark the words of particular importance — not in the cited author's opinion, but rather in the context where the quote appears. Example: pAnother example is this sentence: qHard mlabour/m has turned monkeys into human beings./q Note the use of British spelling./p Using em in this example wouldn't be appropriate because it would imply that “labour” is the most important word in the sentence. No, it just implies that in the context of this page as delivered, the word is emphasised for some reason (which you have to guess from context unless you are going with RDFa or some microformat or something). cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element
On Thu, 08 Feb 2007 07:21:49 +0530, Jonathan Worent [EMAIL PROTECTED] wrote: --- Lachlan Hunt [EMAIL PROTECTED] wrote: Leons, you forgot to CC the list. Leons Petrazickis wrote: Lachlan Hunt wrote: m is for highlighting text that is of some interest to the reader, but it does not alter the meaning of the text itself. Would you say that em is semantic and m is presentational, with the difference from span is in default formatting? Or is meaning not quite the right word - is m like a highlighter in revision change tracking, meant to be seen and then discarded? In what way, apart from denoting that something is particularly relevant within a phrase in a given context, does emphasis change the meaning of something? (I am not being rhetorical here, I genuinely don't understand any difference. I don't know how representative I am of native english speakers, but I am a good translator into at least a couple of languages and I am at a complete loss as to how I would explain the difference in any of them). No, m does have semantics. It marks a specific point of interest, as you might do with a highlighter, it just doesn't alter the meaning of the text itself. Isn't this what strong is for? I.E. signifying the contained text is somehow more important than the surrounding text but not changing the meaning. Strong provides a strong emphasis, no? - where you really want to highlight something a lot... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element
On Thu, 08 Feb 2007 11:01:52 +0530, Lachlan Hunt [EMAIL PROTECTED]wrote:
Charles McCathieNevile wrote:
In what way, apart from denoting that something is particularly relevant
within
a phrase in a given context, does emphasis change the meaning of something?
The spec gives a good example showing how it changes the meaning.
http://www.whatwg.org/specs/web-apps/current-work/#the-em
Sorry, but while those are nice examples, I still don't understand how I could
generalise from them in a way that would make sense to me, sufficient that I
could translate the concept. The closest I can get is that one is meant for
conveying something to do with expression in a human language, while the other
is meant for anything that people wouldn't say. (Maybe I express this better
below - I am not sure).
Which strikes me as an artificial dichotomy.
If I want to note a word in something someone else said ('does emphasis
*change*
the meaning, emphasis mine' is what you find in current usage) which tag do I
use?
Strong provides a strong emphasis, no?
Strong denotes importance (see the spec). This is a change from HTML4,
but HTML4 didn't really define the difference between emphasis and
strong emphasis anyway.
One is stronger than the other. Given that HTML5 allows nesting of emphasis,
there is not much point in having the strong element as well, is there? If em
refers to the importance of some text in the context of the internal semantics
of the text (where m refers to its importance in a context not generally
derived
from its internal semantics), then doesn't nesting it convey weighted
importance?
It seems to me we could do away with both m and strong here and not lose
anything (except that strong appears occasionally in the wild).
cheers
Chaals
--
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
[EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] De-emphasis
On Fri, 09 Feb 2007 00:45:39 +0530, Anne van Kesteren [EMAIL PROTECTED] wrote: On Thu, 08 Feb 2007 20:09:24 +0100, Nicholas Shanks [EMAIL PROTECTED] wrote: Does anyone else have better ideas? Is it really needed? The idea has come up now and then, granted, but it always seemed to me like suggestions to fill some logical hole rather than a real need. I agree with Anne. And saying don't look at this is actually a difficult thing to pull off, so I do not think that the logic actually matches human behaviour, which means this is a recipe for breaking things. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element
On Fri, 09 Feb 2007 00:13:20 +0530, Martin Atkins [EMAIL PROTECTED] wrote: The *meaning* is that the content is highlighted. Or, as the first few definitions I looked at all said, emphasised. -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element [em and strong]
On Thu, 08 Feb 2007 18:05:12 +0530, Øistein E. Andersen [EMAIL PROTECTED] wrote: On 8 Feb 2007, at 9:42AM, Anne van Kesteren wrote: importance is differen[t] from emphasis. This is indeed what the current version of the specification says, but I honestly think this distinction is too artificial to work in practice. Indeed. The Oxford English Dictionary defines one of the meanings of emphasis thus: Stress of voice laid on a word or phrase to indicate that it implies something more than, or different from, what it normally expresses, or simply to mark its importance. The Wikipedia article http://en.wikipedia.org/wiki/Emphasis_(typography) is also relevant to the more general em/strong/m/b/i discussion, as it clearly defines any change in font style as a kind of emphasis. Perhaps the most logical solution would be to keep only em as a general emphasis element and allow i/b/u and possibly others to be used at the author's discretion, but with the same semantics as em. The semasiologists amongst you are unlikely to approve of such a flagrant lack of inherent meaning, but insisting on too fine-grained distinctions, influenced by more or less arbitrary conventions in modern Western typography, is not helpful either. As a semantics fanatic, who happens to believe that the web works best when it aligns with the way people behave, I think this proposal is far and away the most sensible thing I have seen suggested on this topic. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] XSLT: HTML 5 -- HTML
On Fri, 09 Feb 2007 18:12:58 +0530, Jorgen Horstink [EMAIL PROTECTED] wrote: I understand the issue, but why not using some sort of semantic binding between Hx's and the list? Is there some sort of Semantic Binding Language somewhere out there? I've never got the point of the for attribute. That seems to me some sort of basic semantic binding. There are actually other use cases of binding different elements semanticly together. One can say grouping the Hx and List within a DIV element would do just fine, but i do not agree. For example; it would be useful to bind a list item from the index to the actual section. You get my point? This is just some vague idea... I don't know if such a language actually is needed, but how about broaden the scope of the for attribute ? h4 for=myListsome title/h4 ul id=myList lifoo libar /ul for is meant to work like that, although currently only for the label element. A simple alternative would be to make the content model for lists be (hX)?(li)*, no? cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] The m element
On Sat, 10 Feb 2007 17:16:57 +0530, Jens Brueckmann [EMAIL PROTECTED] wrote: To my mind a flag denotes a single point somewhere in the document and does not denote a range. So I associate it with the real-world analogy of a flag placed somewhere in the document. So I am not an advocate of flag I see what you mean. I am in the process of trying to grasp what highlighting acually is. For me it is something different from plain emphasis, although it does sort of emphasise a passage of text. So what do you think about something along the line of ATTN, meaning attention? As far as I understand it, it means something very like emphasis. Expecting people to read the spec for things that have a clear and distinct meaning hasn't worked before, so why would we expect it to work now in the case of a fine semantic distinction? I think there are lots of ways of splitting the hairs that define the difference, but I don't see that the element is worth adding. And I am a native english speaker trying to understand the differences. I can only guess at what those people I work with who speak dreadful english are going to make of it. I guess it could become the google element (if that is the example), or just an optional variant of em (in the same way that strong is often used now). Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
[whatwg] Authoring Re: several messages about HTML5
reasonable and valid, we can prolong their life by generations. The question is how to really promote the things that we want to see - the production of semantically rich and therefore more useful markup. If we are not working with authoring tool developers, we are probably not doing ourselves any favours. If we are not looking at the whole thread that leads to how people learn to express themselves, we're probably going to find that we can never make much progress. (And when we do, we start to deal with things like the semantics of graphics, or of sound, or motion. All of these are critical to people's expression now, in some cases more so than the semantics associated with text documents. And then it becomes interesting...) cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] several messages about HTML5
On Wed, 21 Feb 2007 22:38:48 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: ... most of the tools that have been built have been built by programmers with more experience in WYSIWYG word processors than in semantic markup. The semanticists who have built GUI tools have not had the necessary user interface design skills to produce working programs. What is needed is some work by people who understand both domains. Indeed. And to get users to use them, as has been noted. Actually there have been good semanticists working with Word and Dreamweaver. As someone (Sander?) noted, success might come faster from systems dedicated to doing a small task - CMS, blog systems, etc. Then again... As Adrian said, it is pretty difficult. I worked on it long enough to understand that, if not to come up with all the answers ;). But I am not convinced that it cannot be done, any more than I expect it to be an unquestioned success within my lifetime. Like peace in the Middle East, it's still a worthwhile goal we should actively strive for, IMHO. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
[whatwg] OT history Re: Authoring
On Thu, 22 Feb 2007 15:07:29 +0100, Ron van den Boogaard [EMAIL PROTECTED] wrote: On Wed, 21 Feb 2007 10:47:50 +0100, Charles McCathieNevile wrote: As people got printers and desktop publishing a few people made the crazy multi-font unreadable pages that were all the rage in the mid-80s Rather a judgemental view. Some of the greatest design work was done then. Most notably by Carson. (Remember Raygun magazine?) No I don't, but I agree that great work was done then. It was also the first time a lot of us got the ability to print up menus at the school shop in illegible gothic scripts, and put fancy ribbons on the background to help disguise them. And a lot of us (like me) who have no real design talent spent a while doing things like this because it was new and shiny. (Well, as I said in the bit you quoted, a few people at least). I also have a harsh judgemental view of some of the stuff done in the mid-90s on the web, when for the first time lots of people got let loose on it. At the same time there were lots of very clever people doing very clever stuff. Sadly, the bulk of us are not really outstandingly good at everything we do (by definition, actually). So it isn't hard to find a period in history where a few people have produced rubbish. The point was (in a somewhat rhetorical way) to try and show what ordinary folks tended to do with various new technologies... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Spec should give guidance on compound document integration points
On Sat, 24 Feb 2007 14:53:50 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: The obvious candidates for compound document mixing are SVG and MathML. Also, there are indications that people will want to embed RDF metadata in documents even though the syntax of RDF is designed for external metadata and isn't really all that good for embedded metadata. I think WA 1.0 should give some guidance on these matters. One of the sources of complexity in RDF syntax is the requirement that it could be included in HTML documents in a way that didn't upset legacy browsers. There are assorted use cases for being able to include RDF inside documents. [assorted reasonable suggestions] Where should the RDF element from the RDF namespace be allowed in an XHTML5 host document? (My expectation: It should be allowed as a child of the head element. Other metadata goes there and the contents of head are hidden in legacy browsers, so the text node descendants of the RDF element from the RDF namespace won't leak to presentation in legacy browsers. Also, if conformance checkers don't have a hole that allows embedded RDF, people who want to embed RDF will come up with worse workarounds to avoid eliciting errors in conformance checking. Indeed... To work around the fact that RDF envelope is designed for external metadata and not embedded metadata, XHTML5 should probably suggest that authors use rdf:about= to refer to the current document as per XMP*.) This is standard RDF practice already actually (and fairly common). There are a few edge cases where the semantic power of RDF means that this should not be done, but they probably don't need to be discussed in WHATWG documents as they are unlikely to arise in the usage of people who are reading those documents instead of learning about RDF. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Geolocation in the browser
On Sun, 25 Feb 2007 10:07:58 +0100, Gervase Markham [EMAIL PROTECTED] wrote: Ofcourse there should be option to ask every time, but it can't be the only option. Some users may prefer not to be bothered and have location-based services just working. Also there are IPgeo databases, so some users may want to allow giving away information that has approximately same accuracy. That's a good point; we could probably give data with this approximate accuracy without asking permission. That's probably around the city level of precision? Not necessarily. It's sort of like the accuracy of Google - most of the time you get the right language, but every so often it's just totally b0rken. So while it is a useful guess, you would want to know what the browser is going to submit. And often it is around the country level of accuracy. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
[whatwg] Last Call - XMLHttpRequest
Hi folks, I am pleased to announce that the Web API group has published a Last Call Working Draft of XML HTTP Request at http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/ The Abstract and Status of the Document sections are reproduced at the end of this mail. This draft is for public review and comment, because the working group believes that it has finished the specification. If you have review comments you would like addressed, please send them with either [XHR] or [XMLHttpRequest] at the start of the subject line to the WebAPI list (public-webapi@w3.org) by April 2, 2007. That list is archived at http://lists.w3.org/Archives/Public/public-webapi/ If you need more time to send comments, please send a message saying so, and when you expect your comments to be completed. While we do not guarantee to deal with late comments we will attempt to do so. Thanks to Anne van Kesteren who edited, and the many people who contributed to, the specification. Abstract The XMLHttpRequest Object specification defines an API that provides scripted client functionality for transferring data between a client and a server. Status of this Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. This is the 27 February 2007 Last Call Working Draft of The XMLHttpRequest Object specifcation. Please send comments to public-webapi@w3.org (archived) with either [XHR] or [XMLHttpRequest] at the start of the subject line by 2 April 2007. This document is produced by the Web API Working Group, part of the Rich Web Clients Activity in the W3C Interaction Domain. Changes made to this document can be found in the W3C public CVS server. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] audio vs. video
On Tue, 06 Mar 2007 02:56:31 +1100, Maik Merten [EMAIL PROTECTED] wrote: Elliotte Harold schrieb: If we add a video element, should we for the same reasons add an audio element? If not, why not? I'd say that audio and video actually are pretty similiar. They need controls to start playback, to stop playback, to seek, to pause, ... Perhaps there shouldn't be a video element but more something like mediastream audio=true video=true or something like that. At which point you start heading back to object. It seems we should either take the SMIL approach and make special containers for each kind of media (how many kinds? What is a flash video that has interactive bits? Or an SVG that is mostly video with a few interaction choices? Or interactive SVG with some audio?), or fix object... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Web Forms 2.0 and the W3C Patent Policy
On Wed, 14 Mar 2007 21:28:12 -0700, L. David Baron [EMAIL PROTECTED] wrote: On Wednesday 2007-03-14 21:59 -0400, Matthew Raymond wrote: The following individuals may or may not have agreed to the W3C Patent Policy regarding the Web Forms 2.0 specification: [...] If your name is on the list above, please agree to the license so we can circumvent the patent policy issue in the HTML WG. Let me know if you've already agreed to the policy so I can take you off the list. Sorry, what patent policy issue? I've seen a lot of comments about patent policy flying around, but I haven't seen any concrete statement of an issue that exists. I guess there is an issue that it is difficult for W3C to simply accept a specification without having any clear idea of the patent licensing agreement made by those who developed it (as a minimal exercise in protection from some unpleasant uses of patents). As David says, it isn't a license. But it has been helpful to have the policy active in the past. Anyway, Opera in W3C abides by the W3C patent policy, and has already made the relevant commitment to the WAF group, which has already been working on WF2. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
[whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Mon, 16 Apr 2007 10:32:10 -0400, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 15, 2007, at 11:48 PM, Karl Dubost wrote: in a drag and drop scenario in your mail.app or other HTML authoring tool, you could imagine: [...] When the image is put in the window, a text is requested by the UI (a bit ala ajaxy flickr.) Then the markup could be generated. I don't think this is workable for HTML-generating mail clients or other tools for non-experts. You paste in an image and an area pops up to edit text that won't actually be visible in the mail message. This is likely to cause confusion and annoyance to users, and pretty unlikely to lead to good quality alt text. People would either just press enter, or type a description or caption (and then be annoyed when it disappeared) instead of substitute text. Consider in particular the case where you paste in a chunk of rich text content containing multiple images. There are a lot of ways of doing this in a UI. There are a lot of cases (Maciej you seem to have most of them mentioned already) where the appropriate alt is null. I think it remains the case that for end-user generated content, there will often be semantically meaningful images that are meaningful in themselves and cannot be considered alternate representations of some piece of text. Years of work on accessibility, and a particular focus on authoring tools, suggests that while this is certainly true, There are lots of good ways to enable authors to include an alternate. One of the big frustrations I find with the web today is using assorted tools like wikis and blogsto edit content, and not being able to put useful content for alt where appropriate, and mark it explicitly blank for other cases. Actually, given the relative distribution of disabilities and people, being able to put an image into content in the first place is probably more important than being able to put an alt to it - although the search engine case and various other things irrelevant to accessibility per se add to the value of alt. But it should still be possible. This is not really rocket science, but stuff that people have been working on for decades. When I had my first job working in IT accessibility in 1983 it was already a fairly straightforward problem. That it still gets discussed today is not a very flattering reflection on us as a development community. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Thu, 19 Apr 2007 01:29:39 +0200, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: When I make HTML mail for (solicited) wide distribution, I make sure to include alt text. It's becomes especially important when clients are configured to automatically convert HTML mail to text (as indeed my own Thunderbird currently is). So it's not obvious to me that email composing programs don't need to make it easy to add alt text. ... Maciej Stachowiak wrote: ... I do think that for blogs or wikis where you are publishing to the web audience at large, the editing tools should make it possible and ideally even easy to add alt text. Probably not a mail client though. For the various reasons discussed in this thread, I cannot think of a real justification for making a mail client that breaks one of the basic accessibility features that people understand better than most others. And I can think of plenty of reasons for not doing so. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Thu, 19 Apr 2007 15:43:14 +0200, Thomas Broyer [EMAIL PROTECTED] wrote: 2007/4/19, Matthew Paul Thomas: Thunderbird allows you to set 'alt' ... When you drag/drop an image into a message, the default is alt=. Setting a default of alt= is bad behaviour, since the program has no way of knowing what an appropriate alt might be (the behaviour described with user interaction is ideal), and makes an arbitrary decision that makes it more or less impossible to flag the problem and repair it later. The application should simply leave out the alt attribute. This makes it trivially easy to build a repair application where one is required or desired, and has no practical drawback if the error is left in (given the state of HTML email standardisation...). This should be lear from the W3C's authoring tool accessibility guidelines - http://www.w3.org/TR/ATAG which were desgined with a variety of tools in mind including CMS and email. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Thu, 19 Apr 2007 13:08:33 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 19, 2007, at 3:47 AM, Charles McCathieNevile wrote: Maciej Stachowiak wrote: I do think that for blogs or wikis where you are publishing to the web audience at large, the editing tools should make it possible and ideally even easy to add alt text. Probably not a mail client though. For the various reasons discussed in this thread, I cannot think of a real justification for making a mail client that breaks one of the basic accessibility features that people understand better than most others. And I can think of plenty of reasons for not doing so. I can only imagine it being useful as an advanced feature for experts. Normal people won't understand why a mail program would prompt them to type in some text about an image, that will then not be visible to them or their recipient. We may be closer to agreement than I think. To clarify, does this mean you agree that it should be possible, and ideally easy, to enter an alt text in a mail client, although you would suggest turning that option off by default? As a default, I am happy if clients only get that far. Since easy is such a wollly term, it isn't far at all - it boils down to having some kind of interface for doing this that users can turn on. I think a mail client where you cannot entre alt text for an image is a serious accessibility problem. In various cases where good record-keeping is required, the role of accessibility becomes more important. I guess this is why the US government foramlly requires software to associate text alternatives with images - whe you are sending mail around the department of defense, for example, you may have no idea who will be required to read it in three months or three years. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Sun, 22 Apr 2007 19:58:13 +0200, Kristof Zelechovski [EMAIL PROTECTED] wrote: For (2): alt=(Your browser does not display graphic images). No. Where an alt would be required to makes sense of the image, but is not there, the attribute should simply be left out. Browsers have handled this error condition the best they can for years, and have various strategies for dealing with it ranging from adding image on demand (so users can download it, mail it to someone else, and ask what it is) to doing a complicated lookup on the web or in a local library for a version of the image that has been described. Putting any kind of default means breaking all backward compatibility with this work, and doesn't offer any improvement to anybody. Making up some standard phrase or adding some new attibute still breaks backward compatibility, still offers no substantive improvement, and involves agreeing on something that experts will argue is counterproductive in the first place. Where the author has deliberately decided not to have alt (e.g. because the image doesn't add anything important to a text version of the content), alt= is appropriate. Distinguishing this case from there authors have just not bothered to put anything in (or can't) is an important reason why it is a dreadful default to add. -Original Message- On 4/22/07, Kornel Lesinski [EMAIL PROTECTED] wrote: On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. If the alt attribute is required, what should it be for (2)? Blank? A paragraph describing the vista of the Grand Canyon? Without context, this question is more or less impossible to answer in the general case. A useful alternative will give some information about how this image fits into the content of the page, without going into a detailed description. Ideally, that would be linked via longdesc for something like a sweeping vista of the grand canyon on the rainy winter day that I visited it in 2010, before it had been mostly filled in to provide the carpark that handles the millions of visitors now coming each month to see the exhibition 'what we lost - the empty canyon'. While browser handling of longdesc is almost universally woeful, the only exception I know of being iCab, there are plenty of extensions available, some built into screen readers, that dothe trivially simple job of making the description available. Options might include image 2 - vista of the canyon or image 2 (where the text already says what that is) or all kinds of other things. Writing alternative text is an art, not a science. There are parts of the art that are easily explained (although this discussion is a worrying sign that there is currently a disconnect between the people who understand something of the science and some of the people who are planning how the web should develop). cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Mon, 23 Apr 2007 01:31:46 +0200, Jon Barnett [EMAIL PROTECTED] wrote:
When UAs do what you describe, do they provide a way to download the image
(text browsers) or indicate that what's missing in an image (screen
readers)? What UAs? Is this different from how they currently behave when
alt is present but blank?
This page:
!DOCTYPE html
titleIMG test/title
ol
liImage represents a img src=PICT0023.JPG alt=tree
liImage is content img src=PICT0023.JPG
liImage is decorative img src=PICT0023.JPG alt=''
/ol
Is rendered by Lynx (on my machine) as:
1. Image represents a tree
2. Image represents is content [PICT0023.JPG]
3. Image represents is decorative
Only in (2) does Lynx indicate that the image is missing. That's the
behavior I would expect (even with noalt)
Neither Firefox nor Konqueror distinguish between (2) and (3) with images
disabled.
Opera behaves like Lynx here under default conditions.
noalt is a good idea and leaves no ambiguity.
Except that it breaks all backward compatibility. Providing a way to download
the image is the job of a user agent (Opera's info panel says that there is 1
inline element - or 3 if I change the URIs to be unique), but I don't see how
it comes from markup. (In Opera you can get images with missing or null alt by
using the user mode 'alt text debugger' - you can add the user style
img { min-width:20px ; min-height 20px }
to that if you want to make easier targets for download).
The current draft does say that a missing alt should be treated as if it's
blank. Should that stay the same, or should special semantics be defined
for a missing alt?
User agents should treat this as an error. There is a procedure described in
the User Agent Accessibility Guidelines, which specifies a requirement to
handle this case as different from alt=:
[[[
2.7 Repair missing content (P2) Techniques for checkpoint 2.7
Allow configuration to generate repair text when the user agent recognizes that
the author has not provided conditional content required by the format
specification.
Sufficient techniques
The user agent may satisfy this checkpoint by basing the repair text on any of
the following available sources of information: URI reference (as defined in
[RFC2396], section 4), content type, or element type. Note, however, that
additional information that would enable more helpful repair might be available
but not near the missing conditional content. For instance, instead of
generating repair text on a simple URI reference, the user agent might look for
helpful information near a different instance of the URI reference in the same
document object, or might retrieve useful information (e.g., a title) from the
resource designated by the URI reference.
]]] - http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt
The original, plus some more explanation is provided at
http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-missing-alt
cheers
Chaals
--
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
[EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] video title or alt attribute
Actually the proposed model allows for the use of real content, not just an attribute. This is generally regarded as a better approach for accessibility since it provides much more flexibility (and as it happens provides for better backwards compatibility as well. So instead of video src=foo alt=video of me falling off a bike You can have video src=foo object type=video/theora+ogg src=foo Sorry, it seems your browser isn't playing a href=fooimg src=fooshot alt=br the cool video of me/a that I put here. Pity, you are missing out on watching me fall off a bicycle. pStill, you can always read a href=reviewsthe reviews and descriptions/a from my friends instead... /object /video or something. (If you are using HTML as a source for multilingual sites, or something more complex, you get even more magic. But that's a somewhat advanced use case). cheers Chaals
Re: [whatwg] Allowed characters in attribute names (was: Re: Stepsfor finding one or two numbers in a string)
On Wed, 13 Jun 2007 11:18:28 +0200, Kristof Zelechovski [EMAIL PROTECTED] wrote: Why should I want to use a localized attribute name for the embed element? Because the only languages you speak are mandarin, cantonese and han, and you are using an IDE to develop your system that only requires you to deal with localised stuff for the rest of it. Actually, that isn't using a localised attribute name, just one that actually has a little bit of obvious semantics. Would it make sense to require english speakers to use arabic characters? While english is a very widely spoken language, most people still don't speak a latin language. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Catch up: Speed Dial http://opera.com
Re: [whatwg] Allowed characters in attribute names (was: Re: Stepsfor finding one or two numbers in a string)
On Fri, 15 Jun 2007 00:51:46 +0200, Křištof Želechovski [EMAIL PROTECTED] wrote: Your hypothetical author is unable to insert an embed element because embed is all English to him. Being able to use a Mandarin attribute name will not help him much because he cannot produce the element to use it with. In my example I had the author using an IDE that is localised already for known elements. People really do this. The ones I am aware of actually use japanese or arabic, and do it for convenience - although in principle they can normally work with some kind of latin script, they are not very familiar with english, and would be as happy to use inbed as embed, and happier with something that they recognise more instinctively. China, in particular, is quite keen on localising everything. India seems more inclined to do so, as well, as time goes on and they become a more important player in technology. The scenario does require that the language is extensible - this can be done with XML, presumably including the XML version HTML 5, but not HTML 5 as currently proposed. Considering Arabic script and the like, the time is probably near when we will have to learn it anyway. But we still have some time left, so let's just use the opportunities. The day is full of troubles even without your fantasizing. Thanks for your polite and constructive reply. Cheers, Chris -Original Message- From: Charles McCathieNevile [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 4:40 AM To: Kristof Zelechovski; 'Simon Pieters'; 'Thomas Broyer'; [EMAIL PROTECTED] Subject: Re: [whatwg] Allowed characters in attribute names (was: Re: Stepsfor finding one or two numbers in a string) On Wed, 13 Jun 2007 11:18:28 +0200, Kristof Zelechovski [EMAIL PROTECTED] wrote: Why should I want to use a localized attribute name for the embed element? Because the only languages you speak are mandarin, cantonese and han, and you are using an IDE to develop your system that only requires you to deal with localised stuff for the rest of it. Actually, that isn't using a localised attribute name, just one that actually has a little bit of obvious semantics. Would it make sense to require english speakers to use arabic characters? While english is a very widely spoken language, most people still don't speak a latin language. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [whatwg] getElementsByAttr
On Fri, 06 Jul 2007 21:24:25 +0200, Sander [EMAIL PROTECTED] wrote: I'd like to see a getElementsByAttr method. It would be quite similar as the getElementsByClassName method but with an extra argument: getElementsByAttr(attribute_name, value) The W3C's WebAPI group is specifying a selectors API (the spec was mostly put together by Anne van Kesteren, and now Lachy Hunt is finishing it up), which allows you to do this. The longest running issue is the name of the methods (hopefully we have some closure on that now...) but it lets you do something like methodName(*[lang|=en]) that returns whatever matches that selector the current editor's draft can be found at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [whatwg] getElementsByAttr
On Fri, 06 Jul 2007 23:38:37 +0200, Sander [EMAIL PROTECTED] wrote: Dan Dorman schreef: On 7/6/07, Sander [EMAIL PROTECTED] wrote: I haven't read the whole draft yet so maybe it's in there, but can you, or anyone else, explain why there is both a selectElement and a selectAllElements method? ... If you know you're after one element, you get to deal with it directly rather than first referencing the only contents of a single-element array. But document.selectAllElements(#first)[0] would do the trick. The working group recognises that this is not necessarily critical either way, but decided on having the single element method as an optimisation that does something reasonably useful (in our opinion) for both the implementors of user agents and the authors of code. It is listed as issue 110 in the WebAPI group issue tracker. Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
[whatwg] Nitpicking Re: Editorial Bug: Couple of Appendicies
On Thu, 12 Jul 2007 23:20:32 +0900, Stijn Peeters [EMAIL PROTECTED] wrote: Smylers schreef: A very minor niggle with the 'Structure of this specification' section, which says: There are also a couple of appendices, defining shims for WYSIWYG editors, rendering rules for Web browsers, and listing areas that are out of scope for this specification. http://www.whatwg.org/specs/web-apps/current-work/#structure That's 3 appendicies, which is more than a couple. Smylers —Idiom 14. a couple of, more than two, but not many, of; a small number of; a few: It will take a couple of days for the package to get there. Also, a couple. (http://dictionary.reference.com/browse/couple) I assume this meaning of a couple is used here. It is not the most intelligent use of english.. A couple really does mean two, so the understanding of a native english speaker is that you really are saying two, but lying. In this case, Smylers is correct that using couple is wrong, assuming that using reasonably good english is a goal. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [whatwg] BC AD BCE CE trivia
On Wed, 29 Aug 2007 19:16:10 +0200, timeless [EMAIL PROTECTED] wrote: On 8/29/07, WeBMartians [EMAIL PROTECTED] wrote: There is a disagreement between astronomers and historians about how to count the years preceding year one; astronomers count the BC years astronomically. For example, in the historical practice of counting, the rule of divisibility by 4 revealing the Julian leap-years is no longer valid; these years are, 1 BC, 5 BC, 9 BC, 13 BC... In the astronomical sequence, however, these leap-years are called 0, -4, -8, -12..., and the rule of divisibility by four subsists. In this system we can speak, for instance, of the solar eclipse of -1203-08-28 (twenty-eighth day of August in the year 1204 BC) I must have missed something. But the calendar changed somewhere around 1500, which means the leap year calculations can't simply be done in any way like this. The Gregorian reform that corrected things a bit more, by making every hundredth year that was not also a four-hundredth stop being a leap year. So 2000 was a leap year, but 1900 wasn't. It also shifted the date by acouple of weeks one day (which upset people no end, and during the centuries between then and standardisation introduced lots of interoperability errors). There is not much point trying to calculate dates with a simple algorithm before the gregorian reforms anyway. You need to know which calendar was in use for anywhere you are talking about. In China they switched in 1949, in Russia after the 1917 October revolution (whose name is based on using the right calendar), in England and her American colonies in the 1750s, and I forget if the Orthodox churches accepted the shift, and if so when. Anyway leap years and a regular Julian calendar were instituted by Julius Caesar about 2050 years ago, after the 434-day year which came about because the Pontifex Maximus could just decide how many days a year should have to make it fit. The summary is that a simple Gregorian date algorithm will work for a number of cases where people use a western calendar now, and probably in the future, but falls apart in historical use until the adoption of the Gregorian reforms (depends where you are talking about). There are also issues with dating things in other calendars in current use, like the Japanese (not so hard) and the Hejri (which is particularly tricky). The use cases where it works are probably enough to justify doing it for them, but it should just be admitted that the complexity of dating in general means that outside of this set of cases there is no point trying to use the mechanisms being developed here, and developing further mechanisms that would work universally is complex. (As an historian of the middle ages in Europe (which I used to be), I would explicitly avoid using a defined date syntax to give semantics to a date unless I was confident that I could at least name the applicable calendar - otherwise you have a situation where you can apparently make calculations, but they are based on erroneous assumptions that are likely to lead to errors). Also, the (politically?) correct way to specify BC is Before Common Era, while AD (Anno Domini) is now CE (Common Era). Yes, I would hope not to see AD/BC standardized somewhere. Personally I don't really care much, although I agree with the sentiment behind the name change. The Common Era is less common than it seems though. Japan still uses an imperial system where the year is given by the name of the emperor and the year of his reign, in all kinds of common documents. Islam also has a calendar that is different and is important to practising muslims (even those whose practise is pretty loose), and Judaism has its own calendar (about which I know relatively little). cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
[whatwg] Fwd: Re: Progress Events done event
Forwarded and reply-to set to webapi-public, which is where you should
send things you want actively considered for the W3C progress events spec.
That's the group working on the spec.
I think there is enough detail left in the mail below for webAPI people to
get this. The idea is that it might be helpful to add a done event that
could be trapped instead of having to get the seperate possible events
that mean you are done.
I'm inclined not to add a done event. It invites code repetition in the
browser, which is not helpful in the case of mobile browsers. Also, I
think the example doesn't take into account that where the load is
aborted, or wherer there is an error, you often want to pass by some
relevant function such as explain what happened before calling the code to
clean up the progress bar.
Since progress events are used by other specs, they can add a done if they
really want. But it turns out that for example XHR has onreadystate change
which you can use to get the same info.
What do others think?
Cheers
Chaals
--- Forwarded message ---
From: Garrett Smith [EMAIL PROTECTED]
To: Křištof Želechovski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [whatwg] Progress Events done event
Date: Mon, 10 Sep 2007 23:33:20 +0200
On 8/27/07, Křištof Želechovski [EMAIL PROTECTED] wrote:
Remember that JavaScript is a programming language after all. You can
use a
loop to get rid of the repetitions.
Start from
var done = [load, error, abort]...
and apply the closure image.aEL(?, hPB, false) to it.
Sincerely,
Chris
That is true, in fact, it would also be possible to use Array.forEach
on that array.
The disadvantage is that it still invites code repetition. It is less
concise.
On the contrary:
xhr.addEventListener(done, callCompleteHandler, false);
function callCompleteHandler(e) {
}
Translates the use case to code quite naturally.
I like to make these examples that are conceptually similar:
I'm going to call my friend and then I'm going to the dry cleaner.
vs.
I'm going to call my friend and if she's not available, after that,
I'm going to the dry cleaner and if the call failed, after that, I'm
going to the dry cleaner, and if we talk for a bit, after that...
You get the point. English doesn't have loops or generators (hey
wouldn't that be cool!).
My point is that having a done event is more concise and makes
realizing the use-case requirement to code more explicit.
Garrett
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Sunday, August 26, 2007 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [whatwg] Progress Events done event
==
function showImage(imageHref) {
...
// remove the progress bar when done.
image.addEventListener(load, hideProgressBar, false);
image.addEventListener(error, hideProgressBar, false);
image.addEventListener(abort, hideProgressBar, false);
}
==
This is somewhat verbose. Clearly, the author is forced to repeat
himself when all he really wants to do is hide the progress bar after
the call is done.
--
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
[EMAIL PROTECTED] http://snapshot.opera.com - Kestrel (9.5α1)
Re: [whatwg] Video, Closed Captions, and Audio Description Tracks
On Mon, 08 Oct 2007 02:14:05 +0200, Silvia Pfeiffer [EMAIL PROTECTED] wrote: Hi Chris, this is a very good discussion to have and I would be curious about the opinions of people. An alternative is to use SVG as a container format. You can include captions in various forms, provide controls to swap between thm, and even provide metadata (using some common accessibility vocabulary) to describe the different available tracks, and you can convert common timed text formats relatively simply. For implementors who already have SVG this is possibly a good option. Loading HTML itself with everything seems like overkill to me. The case where you have fallback content means you can deal with some semi-capable format that doesn't allow a full range of accessibility options in a single resource... [snip] I think we need to understand exactly what we expect from the caption tracks before being able to suggest an optimal solution. Agree. I'm more likely to be involved if the discussion takes place on the W3C mailing list. On 10/8/07, Chris Double [EMAIL PROTECTED] wrote: The video element description states that Theora, Voribis and Ogg container should be supported. How should closed captions and audio description tracks for accessibility be supported using video and these formats? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Re: [whatwg] Removal of Ogg is *preposterous*
On Tue, 11 Dec 2007 17:11:57 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 11 Dec 2007, at 13:36, Maik Merten wrote: The old wording was a SHOULD requirement. No MUST. If the big players don't want to take the perceived risk (their decision) they'd still be 100% within the spec. Thus I fail to see why there was need for action. There's a question within the W3C Process whether patents that are covered by a SHOULD via a reference are granted a RF license similarly to anything that MUST be implemented. Both Nokia and MS raised concerns about this relating to publishing the spec as a FPWD. And these concerns are total rubbish (as pointed out by Apple and others): [[[ 8.1. Essential Claims Essential Claims shall mean all claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by implementation of the Recommendation. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the normative portions of the Recommendation. Existence of a non-infringing alternative shall be judged based on the state of the art at the time the specification becomes a Recommendation. ]]] - http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential In other words, the patent policy makes it clear that to be covered, something must be required in order to implement. A SHOULD-level requirement is clearly not required. So any such concern about the wording that was in the spec is more FUD than fact. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] How to use SVG in HTML5?
On Thu, 24 Jan 2008 04:19:37 +1100, Mathieu HENRI [EMAIL PROTECTED] wrote: James Graham wrote: David Gerard wrote: ... I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported... Supporting img src=foo.svg is a requirement of SVG 1.1 [1] ... It is true that you can't use inline markup. As far as I know, img src=foo.svg is only supported in Opera 9.5 betas (maybe webkit nightlies, I forget). It's also bad HTML, since it lacks any kind of fallback. But you can use object data-foo.svg/object (again bad HTML, it should generally have some kind of fallback content - and a size). Unfortunately, of course, IE is still holding you back from doing it on the open web that simply :( cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] How to use SVG in HTML5?
On Thu, 24 Jan 2008 06:44:59 +1100, Sam Ruby [EMAIL PROTECTED] wrote: On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ An image is not a replacement for text in the real world, only in Ian's current drafts. And where it is, SVG is ideal for having beautifully styled selectable interactive text that is lightweight and easy to create (or heavyweight and bloated if you use something like inkscape, but still easy to create and easy to automagically optimise to something lightweight). Which is why I disagree thoroughly with Chris' assertion here. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] accesskey
On Mon, 28 Jan 2008 10:02:26 +1100, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: ... Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The problem does indeed have a god solution, which is to remove the stupid suggestion about the activation behaviour (alt/cmd/etc) in the spec. iCab, Opera, Amaya and Firefox have already implemented something intelligent that lets you avoid conflicts. The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. And an unimaginatve and unintelligent approach anyway. ... Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and 5-way directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. ... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. They do. However, accesskey, which is to primarily designed to give an increased navigation priority to certain links, is very useful for handsets, and not actually very complicated to implement, in a way that is consistent with the existing markup. It might not be the same across all implementations, but there is very little restriction needed to make an implementation compatible with almost any imaginable UI. And all of this has been proposed before, implemented by people in various ways in javascript or via proxy-based scripting as well as in user agents, and is hardly rocket science. http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html gives you a set of implementation techniques, links to a set of minimal changes required to the spec, etc. (There is more that could be done in an advanced implementation, but it isn't really complicated). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Opera SVG Re: How to use SVG in HTML5?
Hi Vlad, as I read these, Opera is doing the right thing. Since the SVG you use doesn't have a viewBox attribte to say how the thing should fit, it creates an initial viewport where the size in px that the image element gets corresponds to a view in SVG user units. So a 300x100 img shows a portion of the SVG that goes from 0,0 (the top left) to 300,100 at the bottom right - in other words, only a part of the tiger. If you add a viewBox then the preserveAspectRatio attribute can be used, and has the default value of none, which squeezes the SVG to fit the space you give it. Without viewBox the preserveAspectRatio has no effect, since there is nothing that says how what size the contents of the SVG should be. So I don't think there is a bug at all. If you use something like inscape that doesn't add a viewBox, your SVG will do what your demos do. We can in fact change that in Opera for example by adding a default viewBox of some kind, but technically that is in violation of the current specs for SVG up to and including 1.2. I've cc'ed Erik, our SVG lead and the hair of the SVG WG, in case he wants to offer anything more, or correct anything I have misunderstood. cheers Chaals On Sat, 26 Jan 2008 00:10:08 +1100, Vlad Alexander (xhtml.com) [EMAIL PROTECTED] wrote: Hi Charles, Thanks for looking into this. Here you go: http://xhtml.com/misc/svg-img1.htm http://xhtml.com/misc/svg-img2.htm http://xhtml.com/misc/svg-img3.htm Regards, -Vlad http://xhtml.com Original Message From: Charles McCathieNevile Date: 2008-01-24 10:47 PM Hi Vlad, On Fri, 25 Jan 2008 00:50:45 +1100, Vlad Alexander (xhtml.com) [EMAIL PROTECTED] wrote: ... I tested Opera's support for SVG through the img element and it incorrectly clips the SVG image. The width and height attributes of the img element need to set the viewport for the SVG image and scale the SVG non-uniformly to fit the viewport. What was your test case? Can you share it so we can check whether this is a known problem or issue? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] accesskey
On Tue, 29 Jan 2008 03:31:46 +1100, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 25-01-2008, Pt o godzinie 23:06 -0500, Jean-Nicolas Boulay Desjardins pisze: ... But what would happend if this was to happend: a href=bob.html accesskey=bBob web page/a a href=alex.html accesskey=bAlex web page/a Again this is allowed in the present web standard, but if you think about it its illogical, on what bases thus the browser decide wich one to access first or should it open the tow? The visible and enabled elements marked with the same access key should take focus in turn and in page order. Indeed... User agents must, in any case, be free to reassign access methods (for example using a key other than the one the author suggested). This is one reason they might do that (a more common reason would be that there isn't a readily available 語 key...). Since it is critical user agents can do this, user agents, not authors, should be responsible for telling the user how to activate the things that have access keys. (This was envisioned in the User Agent Accessibility Guidelines, where it has its own checkpoint [1]). So the user agent can actually decide to leave the keys as they are and allow cycling through them (IE does this in some versions at least), or change the key (or other behaviour) that triggers the effect and of course make it clear to the user what the actual activation method is. If the element is an active element, its action should not be performed. Hmmm. I am not sure about this. In general, I prefer an acceskey mechanism that activates controls (although it should be configurable), and a user agent that just re-maps doubled accesskeys. I certainly don't think that we should be overly prescriptive about how to handle the situation. This is, after all, primarily a question of user interface design, not markup design. cheers chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] accesskey
On Mon, 28 Jan 2008 16:31:04 +0100, Mikko Rantalainen [EMAIL PROTECTED] wrote: Matthew Paul Thomas wrote: Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. It does. Just allow the UA to accept the key a a hint, but provide the real binding itself. (And therefore require the UA and not the author to provide dscoverability for things with accesskey. As envisioned by the UAAG most of a decade ago). The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. Perhaps the accesskey should be kept but its meaning should be transformed a bit. Instead of being a key (letter) it should be a keyword for a behavior. A good accesskey values could be home, index, search, contact. The user then could bind the home accesskey to any home button of his selection. It could be CTRL+H or perhaps F11 instead. Some keyboards have additional multimedia keys that could easily be used for such behavior. This functionality is already available via the rel attribute, and where there are good common values it makes more sense to use those than accesskey in the first place. ... So my suggestion is to turn the accesskey to a tag of the behavior or feature linked to the element. One could argue that instead the rel attribute should be used for such behavior and I really cannot claim otherwise... No :) Accesskey is where there isn't something obvious - a function that hasn't been common (send was once such a function on the web, before the growth of web-based mail systems. Add to shopping basket is another. I am sure there are new services we haven't developed yet...). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] several messages about figure and related subjects
On Tue, 26 Feb 2008 06:16:15 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in figure captions (let alone more
than one form control) really more important than ability to style them
sanely? Putting a form control in a figure caption seems unlikely to me.
What would you recommend for the am I hot or not and the like? At first
glance, that seems like a reasonable use case to me.
...
A new element would be a neat solution, but frankly I'm out of words to
use, and if we keep adding new ways to mark up titles and captions and
legends and labels, authors aren't going to be able to work out when
they should use each element...
It seems to me that the problems with adding a new element are purely
aesthetic, while the problems with reusing 'legend' are practical and
harm deployment of the new element.
Agreed.
I think our only option is to use legend, and, while in the migration
period, have people use markup like:
figure
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan class=legend ... /span/legend
is uglier than writing something like figcaption ... /figcaption.
And the migration period could take more than a decade. Given the
lengths that HTML5 goes to so that it can degrade gracefully, this
sounds like a high price to pay to avoid adding an element.
cheers
chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Usemap and ismap for canvas tag
On Tue, 04 Mar 2008 13:40:52 +0900, Greg Houston [EMAIL PROTECTED] wrote: Wouldn't it make more sense just to use SVG? ... So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. This seems to make sense to me. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Right. On the other hand, loading it with a DOM would slow it down to the point that it loses its major benefit over SVG (at least as I see it) - the fact that it is relatively lightweight, ergo faster. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] ARIA
On Fri, 07 Mar 2008 10:56:22 -0800, John Foliot [EMAIL PROTECTED] wrote: James Graham wrote: What's the easiest way to test existing aria implementations on Mac/Linux (I don't have access to a Windows box)? Firefox 3 + Accessibility Extensions for Mozilla http://cita.rehab.uiuc.edu/software/mozilla/installation.php On Mac, Opera 9.5 beta - latest weekly at http://my.opera.com/desktopteam With VoiceOver, you can set it to show what it is reading out as a transparent box on the screen. I find that very useful for testing. /me reaches across and slaps john with a wet fish, for not mentioning Opera ;) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 16:46:45 +0100, Paul Waring [EMAIL PROTECTED] wrote: On 17/03/2008, Nicholas C. Zakas [EMAIL PROTECTED] wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Is there an example of something which you think should be seen by screen readers but not by sighted users? Also, isn't this doing something similar to what display : none does in CSS (browsers won't render this content, but I presume screen readers will still read it out)? Bad assumption - they don't read it out. They read what is put on the screen. (Well, sort of - what they actually do is parse the DOM themselves quite often, as well). One reason for this is that a lot of authors put stuff there for screen reader users that just adds to the clutter on their page - an easy mistake if you're not used to what screen readers are actually like to work with. Designers put things (including useful things) on pages for screen reader users, and then hide them in various ways - things like [D] links, the skip to content links, alternatives for images that are more than just a text string so can't go in as alt, etc. I don't like the use case, but it is pretty common and if you want to be compatible with the real web we should have a way to deal with it. At the moment the most commonly successful technique is positioning things offscreen, but that's not a great solution either. In my ideal world, people would actually implement the aural style, but I think we are the biggest implementation of that and we only do it on windows for the voice plugin :( cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 20:07:52 -, Paul Waring [EMAIL PROTECTED] wrote: On 17/03/2008, Charles McCathieNevile [EMAIL PROTECTED] wrote: Bad assumption - they don't read it out. They read what is put on the screen. (Well, sort of - what they actually do is parse the DOM themselves quite often, as well). One reason for this is that a lot of authors put stuff there for screen reader users that just adds to the clutter on their page - an easy mistake if you're not used to what screen readers are actually like to work with. Ah, it would appear that screen readers have got a bit more advanced since the last time I looked into them (which admittedly was some time ago) - back then I think many of them still read out 'hidden' text. Must have been a very long time ago. They generally haven't done that. In my ideal world, people would actually implement the aural style, but I think we are the biggest implementation of that and we only do it on windows for the voice plugin :( If there is already something which does this then, is there really a need for a noview element? I don't think introducing a new element will change anything, it will just complicate the things that we should be focusing attention on, so I don't think there is any need for such an element. cheers chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 20:05:22 -, Simon Pieters [EMAIL PROTECTED] wrote:
On Mon, 17 Mar 2008 18:17:19 +0100, Sam Kuper [EMAIL PROTECTED]
wrote:
On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
Could you elaborate more on what problem you are trying to solve?
I wonder if this http://www.alistapart.com/articles/fir/ is one of the
problems to do with content for sighted/unsighted viewers it might be
nice
to have a good solution to in HTML5?
I think this is more of a problem with CSS, and one that is, AFAICT,
solved with CSS3 generated content (which is implemented in Opera,
although I have not tested it in Opera in combination with a screen
reader):
h1 { content:url(foo.png) }
It doesn't work with a screen reader in either Safari or Opera using
VoiceOver - and I wouldn't expect it to until differentiating media types
is reliably implemented. So this seems like an approach to avoid - the use
of off-screen positioning is less harmful (if still not that great). If
anyone wants a test case, let me know - I would expect that in Windows no
screen reader will read the content either, but don't have a windows
machine to test (although I need one - at least I have a handful of
windows screen readers).
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Are unfocusable elements focusable with tabIndex=-1.
On Wed, 23 Apr 2008 04:35:39 +0800, Aaron Leventhal [EMAIL PROTECTED] wrote: So how do I know if this has been registered as a pending issue that will be fixed in the spec? As long as the spec remains the same as the W3C HTML 5 spec you can also ask someone to raise an issue in that group. There is an instance of W3C's tracker following various issues on the mailing list (where you can see if it picked up a relevant thread - and link it if it didn't happen). http://www.w3.org/html/wg/tracker/ cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Expanding datetime
On Fri, 25 Apr 2008 07:54:37 +0800, Christoph Päper [EMAIL PROTECTED] wrote: Henri Sivonen: Date form widgets are meant for airline and hotel reservations What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites? Hmmm. The ability to show continental drift using a timeline probably doesn't need a datetime (century is usually pretty fine-grained). But virtual skies are pretty important to historical as well as future stuff. There must be about half a billion people who would like to be able to recreate the night skies around Bethlehem in a period between say -0010-01-01 and 0004-01-01 to see if there is something interesting happening. There are various ecological things that are well-suited to timelines stretching back 2009 years. Urban planning and economics is another area that may use the ability to look at things 2009 years ago. Historical weather modelling is another - there are points in history where the date is actually relevant, in particular the ability to match up phenomena known to have occurred in order to synchronise dates calculated according to different and not entirely-known methods. As an historian, these seem useful things to be able to do. It would seem to me as a browser maker that this doesn't actually complicate life a whole lot (I may be wrong - I haven't thought hard about the implications yet). As a standards guy, I do not see that being able to do this would introduce any particular complications (beyond a few more test cases). I am inclined to think that the use cases justify the cost, at least enough to investigate further. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Context help in Web Forms
On Mon, 02 Jun 2008 09:40:55 -0300, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Ian Hickson wrote on 27/05/08 07:47: On Mon, 12 Nov 2007, Matthew Paul Thomas wrote: On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: On Mon, 13 Jun 2005, Matthew Thomas wrote: ... Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. ... The data-* attributes are intended for scripts like this. ... The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. Indeed. There is an attribute for this called contexthelp or something that JAWS implemented years ago, collaborating with the US Treasury or seomthing. I proposed it to the whatwg a couple of years ago but my recollection is that this was rejected as not useful or important or something. Certainly it seems mor sensible to go with existing implementation than to make up something incompatible, and it seems that using data-* means we will actually get several dozen different versions of this - using ARIA would be an approximately infinitely better alternative. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. Sounds like a semantic web project to me, infobot. (Personally I think that would be useful, but at that point I'd switch to basing my work on XML anyway, where there are infrastructures for this kind of thing). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] access to local path in input type=file
On Thu, 20 Mar 2008 20:58:03 -0300, ddailey [EMAIL PROTECTED] wrote: In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user to change the src attribute of an image based on her perusal of local file space. Opera 9.5 doesn't seem to allow access to the path data necessary for accomplishing this rollover effect, and I suspect that may be how it is supposed to be according to emerging standards. ... Hi David, you might be interested in the fileIO proposal [1] from Opera in the WebAPI group at W3C, which is designed to allow for this kind of use case. [1] http://dev.w3.org/2006/webapi/fileio/fileIO.htm cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
[whatwg] language quibbles: either works Re: same-origin versus same origin
On Sat, 05 Jul 2008 03:17:50 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008, Anne van Kesteren wrote: http://www.w3.org/html/wg/html5/ has some usage of same-origin while it seems that the intention is for it to be all same origin. I'd prefer if it was all same origin (apart from tokens, of course) as that's what I/I'll use in XLMHttpRequest et al. The intent is to use same-origin when the term is used as an adjective and same origin when it is used as a noun phrase. That, as far as I understand, is correct English grammar. Actually I am pretty sure that either are correct in the context of an attempt to describe the usage that constitutes english grammar. English grammar, unlike many other languages, does not have a formal definition, nor any body capable of making one. This lack of formal precision is a drawback when using it to describe technical things - but one counterbalanced by the fact that many of the people who want to understand the descriptions have some level of familiarity with it. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://www.opera.com
Re: [whatwg] Making it possible to do an anchor link to any DOM node
On Wed, 18 Jun 2008 23:31:46 +0200, Elliotte Rusty Harold [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: Hi, Currently when linking to specific places in a document one is limited to the places the original author made linkable via an anchor a tag. While this is a nice touch (though not well exposed by modern browsers), the reality is that most of the time the person who writes a document that links to the original page has a better idea of where exactly he wants to link to. Actually, what you link to these days is any element with an ID attribute. What you're proposing is to reinvent XPointer. As originally done most of a decade ago. There may still be traces available via http://jibbering.com/discussion/fuzzy-pointers.html cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://www.opera.com
Re: [whatwg] Application deployment
On Sun, 27 Jul 2008 23:05:44 +0200, Philipp Serafin [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 8:44 PM, Russell Leggett [EMAIL PROTECTED] wrote: ... This is a suggestion that is more helpful to larger single page web applications, but could also be very helpful to other resource intensive web pages. My thought is that it could be extremely helpful to create some kind of web application deployment format. I think for HTML, this is already covered by MHTML http://tools.ietf.org/html/rfc2557. The problem here is probably to bring more people to implement this one. That's one common approach. An alternative, which is used to get a bit more functionality by people who were thinking the same as you and building platforms to do it, is the widget packaging spec - http://www.w3.org/tr/widgets (but it isn't developed by WHAT-WG). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://www.opera.com
Re: [whatwg] video tag : loop for ever
On Sun, 28 Sep 2008 01:27:54 +1000, Jorgen Horstink [EMAIL PROTECTED] wrote: I understand the conceptual problem with this, but why don't you just use a large number? If the video is 1 sec, with a playcount set to 999 it will keep running at least three months; longer than any webpage is in memory. Except if it is being used for an advertising display, or the like, and happens to be around for a long time. Why not define a way to say forever that means it (and doesn't require us to count the loops in our implementation)? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://www.opera.com
Re: [whatwg] Context help in Web Forms
Adding HTML-WG so people know what's going on and can comment if necessary. On Wed, 22 Oct 2008 14:42:48 +0700, Ian Hickson [EMAIL PROTECTED] wrote: [in the context of a request for a way to identify context-specific help, e.g. some further information about a given form field that can be made available without requiring the user to read it]. ... I don't understand how inline text is inaccessible. Could you elaborate? An example would be useful. Large quantities of text reduce the overall accessibility of a page in a couple of ways. The most common is actually making the page harder to read - and reading difficulties are very common as a type of disability. The effect can be very mild (it is a bit slower) or very severe (many people actually find it incredibly difficult to read something if there is too much text there). (For this reason, designers will often look for ways not to have the text present in the page's default view...) The other common problem it introduces is reducing the ability of users to navigate efficiently. This applies especially to screen reader users who are scanning text by skipping through it. One of the benefits HTML provides over plain text is the various navgiable structures to improve this situation - having a lot of inline text can negate some of that improvement, especially if it is not marked in a way that makes it clear that it is ancillary to the main content. (One of the problems with visible metadata is that people assume that since it is visible it doesn't really need more markup...) Hixie had said... Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Chaals replied: Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Thanks, this seems sound to me. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] accesskey attribute with display:none elements
On Fri, 28 Nov 2008 05:01:42 +1100, Olli Pettay olli.pet...@helsinki.fi wrote: On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote: Perhaps a *good* rationale could be, if you can't see the control, There are other modalities than just visual. Sure. But users generally expect the page to work the same dependent on usage, not dependent on their modality (which the page can't be sure of anyway). So, I stand up for standardizing the disallow accesskey activation for 'display:none' elements behaviour. So you're willing to break accesskeys on some websites. Note, I'm not very strongly supporting accesskeys on display:none elements, but breaking existing web sites doesn't sound good. In principle I think it makes good sense for accesskeys not to work on things that are disply:none. But in practice, I think Olli's argument (it ain't broke so lets not 'fix' it - especially in a way that breaks stuff) is the one that carries the most weight. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] attribute media on script element
On Sat, 15 Nov 2008 08:18:25 +1100, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Nov 2008, Filippo Levizzani wrote: Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) This doesn't really work because media queries are supposed to change dynamically. The real solution here is a combination of XBL2 and a new API in the CSSOM-View draft (window.media). Hi Ian, I can see the value in this (but then, I also see the value in media types in styling - something it seems some browser makers are not really interested in), and I agree with David's concern that it can have some pretty costly implications. Can you explain why XBL2 is part of the solution here? It seems you have something in mind that I don't understand yet. thanks Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Trying to work out the problems solved by RDFa
that it will be gamed. However, that's the reality that we have to live with when introducing any new web-based technology. It will be mis-used, abused and corrupted. The question is, will it do more good than harm? In the case of RDFa /and/ Microformats, we do think it will do more good than harm. For search engines, I am not convinced. Google's experience is that natural language processing of the actual information seen by the actual end user is far, far more reliable than any source of metadata. Thus from Google's perspective, investing in RDFa seems like a poorer investment than investing in natural language processing. Indeed. But Google is something of an edge case, since they can afford to run a huge organisation with massive computer power and many engineers to address a problem where a near-enough solution brings themn the users who are in turn the product they sell to advertisers. There are many other use cases where a small group of people want a way to reliably search trusted data. From global virtual library systems to a single websites, there are many others who find that processing structured data is more efficient for their needs than doing free-text analysis of web pages (something that they effectively contract out to Google, Ask, Yahoo! and their many competitors who specialise in it). Some of these are the people whe have decided that investing in RDFa is a far more valuable exercis than trying to out-invest Google in natural language processing. This email is already too long for most people to get through it :( I believe that this discussion is going to last for some time (I cannot imagine why, given the HTML timeline, it would need to be resolved before June), so there will be time for others to discuss more fully the many points Ian raises as ones he would like to understand. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Trying to work out the problems solved by RDFa
to the document, would be helpful. As a trivial example, it would be useful to me in working to improve the Web content we produce at Opera to have a nice mechanism for identifying the original source of various parts of a page. What would you do with scoped copyright information, anyway? I can see images being an issue, but ideally information about a resource should be kept in that resource, and as such the licence should be embedded in the image rather than given by a Web page. In the case of particular sections having particular licences, is there any practical use of marking up different sections with different licences over just doing that with text? Mash-ups. If they have a use-case, and I think it is widely accepted that they do, then it would seem obvious that being able to identify the source of each part, and any conditions that vary between different sources, is a use case. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Trying to work out the problems solved by RDFa
On Sat, 03 Jan 2009 04:52:35 +1100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile cha...@opera.com wrote: On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell a...@takkaria.org wrote: On 2009-01-01 15:24, Toby A Inkster wrote: The use cases for RDFa are pretty much the same as those for Microformats. Right, but microformats can be used without any changes to the HTML language, whereas RDFa requires such changes. If they fulfill the same use cases, then there's not much point in adding RDFa. ... Why the non-response? Because the response comes in the next paragraph, to the first question that was worth asking. So why RDFa and not Microformats? (I think the question should be why RDFa is needed *as well as* µformats) This is correct. Microformats exist already. They solve current problems. (Elsewhere in this thread you wrote [[[ It has not yet been established that there is a problem worth solving that metadata would address at all. ]]] Do you consider that µformats do not encode metadata? Otherwise, I am not sure how to reconcile these statements. In any case I would greatly appreciate clarification of what you think microformats do, since I do believe that microformats are very explicitly directed to allowing the encoding of metadata, anbd therefore it is not clear that we are discussing from similar premises). Are there further problems that Microformats don't address which can be solved well by RDFa? Are these problems significant enough to authors to be worth addressing in the spec, or can we wait and let the community work out its own solutions further before we make a move? In my opinion, yes there are further problems µformats don't solve (that RDFa does), yes they are significant, and the community has come up with a way to solve them - RDFa. Microformats are the metadata equivalent of Flash-based video players. They are hacks used to allow authors to accomplish something not explicitly accounted for in the language. Are there significant problems with this approach? Yes. The problems are that they rely on precoordination on a per-vocabulary basis before you can do anything useful with the data. In practical usage they rely on choosing attribute names that hopefully don't clash with anything - in other words, trying to solve the problem of disambiguation that namespaces solves, but by choosing names that are wierd enough not to clash or by circumscribing the problem spaces that can be addressed to the extent that you can expect no clashes. (This is hardly news, by the way). Is metadata embedding used widely enough to justify extending the language for it, or are the current hacks (Microformats, in this case) enough? Are current metadata embedding practices mature enough that we can be relatively sure we're solving actual problems with our extension? Current metadata embedding is done using µformats, and it's pretty clear that they are not sufficient. A large body of work uses RDF data models (Dublin Core, IMS, LOM, FOAF, POWDER are all large-scale formats. The people who are testing RDF engines with hundreds of millions of triples and more are doing it with real data, not stuff generated for the experiment). It is also clear that people would like to develop further small-scale formats, and that µformats through its requirement for community consultation is effectively too heavyweight for the purposes of many developers. These are all questions that must be asked of any extention to the language. Firstly, RDFa provides a single unified parsing algorithm that Microformats do not. ... This is not necessarily beneficial. If you have separate parsing algorithms, you can code in shortcuts for common use-cases and thus optimise the authoring experience. On the other hand, you cannot parse information until you know how it is encoded, and information encoded in RDFa can be parsed without knowing more. And not only can you optimise your parsing for a given algorithm, you can also do for a known vocabulary - or you can optimise the post-parsing treatment. What is the benefit to authors of having an easily machine-parsed format? Assuming that the format is sufficiently easy to write, and to generate, I am not sure what isn't obvious about the answer to the question. (In case I am somehow very clever, and others aren't, the benefit is that it is easy to machine parse and use the information). Are they greater than the benefits of a format that is harder to parse, but easier for authors to write? For a certain set of authors, yes the benefits are greater. Also, as has been pointed out before in the distributed extensibility debate, parsing is a very small part of doing useful things with content. Yes. However many of the use cases that I think justify the inclusion of RDFa are already very small on their own
Re: [whatwg] Trying to work out the problems solved by RDFa
On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino alex.baldacch...@email.it wrote: Charles McCathieNevile ha scritto: ... it shouldn't be too difficoult to create a custom parser, comforming to RDFa spec and availing of data-* attributes... That is, since RDFa can be emulated somehow in HTML5 and tested without changing current specification, perhaps there isn't a strong need for an early adoption of the former, and instead an emulated mergence might be tested first within current timeline. In principle this is possible. But the data-* attributes are designed for private usage, and introducing a public usage means creating a risk of clashes that pollute RDFa data gathered this way. In other words, this is indeed feasible, but one would expect it to show that the data generated was unreliable (unless privately nobody is interested in basic terms like about). Such results have been used to suggest that poorly implemented features should be dropped, but this hypothetical case suggests to me that the argument is wrong, and that if in the face of reasons why the data would be bad people use them, one might expect better usage by formalising the status of such features and getting decent implementations. What is the cost of having different data use specialised formats? If the data model, or a part of it, is not explicit as in RDF but is implicit in code made to treat it (as is the case with using scripts to process things stored in arbitrarily named data-* attributes, and is also the case in using undocumented or semi-documented XML formats, it requires people to understand the code as well as the data model in order to use the data. In a corporate situation where hundreds or tens of thousands of people are required to work with the same data, this makes the data model very fragile. I'm not sure RDF(a) solves such a problem. AIUI, RDFa just binds (xml) properties and attributes (in the form of curies) to RDF concepts, modelling a certain kind of relationships, whereas it relies on external schemata to define such properties. Any undocumented or semi-documented XML formats may lead to misuses and, thus, to unreliably modelled data, ... I think the same applies to data-* attributes, because _they_ describe data (and data semantics) in a custom model and thus _they_ need to be documented for others to be able to manipulate them; the use of a custom script rather than a built-in parser does not change much from this point of view. RDFa binds data to RDF. RDF provides a well-known schema language with machine-processable definition of vocabularies, and how to merge information between them. In other words, if you get the underlying model for your data right enough, people will be able to use it without needing to know what you do. Naturally not everyone will get their data model right, and naturally not all information will be reliable anyway. However, it would seem to me that making it harder to merge the data in the first place does not assist in determining whether it is useful. On the other hand, certain forms of RDF data such as POWDER, FOAF, Dublin Core and the like have been very carefully modelled, and are relatively well-known and re-used in other data models. Making it easy to parse this data and merge it, according to the existing well-developed models seems valuable. Ian wrote: For search engines, I am not convinced. Google's experience is that natural language processing of the actual information seen by the actual end user is far, far more reliable than any source of metadata. Thus from Google's perspective, investing in RDFa seems like a poorer investment than investing in natural language processing. Indeed. But Google is something of an edge case, since they can afford to run a huge organisation with massive computer power and many engineers to address a problem where a near-enough solution brings themn the users who are in turn the product they sell to advertisers. There are many other use cases where a small group of people want a way to reliably search trusted data. I think the point with general purpose search engines is another one: natural language processing, whereas being expensive, grants a far more accurate solution than RDFa and/or any other kind of metadata can bring to a problem requiring data must never need to be trusted (and, instead, a data processor must be able to determine data's level of trust without any external aid). No, I don't think so. Google searches based on analysis of the open web are *not* generally more reliable than faceted searches over a reliable dataset, and in some instances are less reliable. The point is that only a few people can afford to invest in being a general-purpose search engine, whereas many can afford to run a metadata-based search system over a chosen dataset, that responds to their needs
Re: [whatwg] Trying to work out the problems solved by RDFa
On Sun, 04 Jan 2009 16:37:08 +1100, timeless timel...@gmail.com wrote: On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile cha...@opera.com wrote: No, I don't think so. Google searches based on analysis of the open web are *not* generally more reliable than faceted searches over a reliable dataset, and in some instances are less reliable. dunno. i use google to search apple, msdn, and a number of other technical resources because the actual technical resource search engines are unusable/useless. Sure. That's wonderful that Google are so good (or sad that the people who make the information you rely on are so useless). i also use gmail (which i presume shares some intelligence with google) to manage access to bug databases, because it's faster/smarter than the actual database search engine.. And I use my Opera's filters to search for certain things because they are far more efficient than the full-text search I also use. It depends on the use cases. My point is not that Google is bad. It is that there are all kinds of search where it is not the best. One set are those which reliy on faceted information and on well-developed metadata. I don't know what searches you do, but I know that some databases I search are dreadfully maintained and free-text is the only sensible approach, while others are well-designed and I can get better results from a tool designed for the job I am trying to do. Anecdotal evidence that demonstrates there is a use case for Google is something we probably don't need. I think that we are all convinced that Ian's employer is important - not least because it kindly pays Ian for his work. I think the question is to establish what cases doesn't Google serve. (Well, and the rest of the search engine market, who I believe are the majority of searches performed globally even on the public internet). And my further question to Ian is what are the criteria for deciding whether a case is sufficient. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Trying to work out the problems solved by RDFa
On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen hsivo...@iki.fi wrote: On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote: On 2/1/09 10:38, Henri Sivonen wrote: Is the problem in the case of recipes that the provider of the page navigation around the recipe is unwilling to license the navigation bits under the same license as the content proper? I thought Toby's example was that each recipe on the page needed a different licence, rather than a distinction between the main content area and the navigation. Oh. That can be solved by giving each recipe its own URI HTML page and scraping those pages instead of summary pages that might contain multiple recipes. Sure. In which case the problem becomes doing mashups where data needs to have different metadata associated is impossible, so the requirement is enable mashups to carry different metadata about bits of the content that are from different sources. A use case for this: There are mapping organisations and data producers and people who take photos, and each may place different policies. Being able to keep that policy information helps people with further mashups avoiding violating a policy. For example, if GreatMaps.com has a public domain policy on their maps, CoolFotos.org has a policy that you can use data other than images for non-commercial purposes, and Johan Ichikawa has a photo there of my brother's café, which he has licensed as must pay money, then it would be reasonable for me to copy the map and put it in a brochure for the café, but not to copy the data and photo from CoolFotos. On the other hand, if I am producing a non-commercial guide to cafés in Melbourne, I can add the map and the location of the cafe photo, but not the photo itself. Another use case: My wife wants to publish her papers online. She includes an abstract of each one in a page, but because they are under different copyright rules, she needs to clarify what the rules are. A harvester such as the Open Access project can actually collect and index some of them with no problem, but may not be allowed to index others. Meanwhile, a human finds it more useful to see the abstracts on a page than have to guess from a bunch of titles whether to look at each abstract. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Trying to work out the problems solved by RDFa
On Mon, 05 Jan 2009 00:17:39 +1100, Henri Sivonen hsivo...@iki.fi wrote: On Jan 3, 2009, at 17:05, Dan Brickley wrote: But perhaps a more practical concern is that it unfairly biases things towards popular languages - lucky English, lucky Spanish, etc., and those that lend themselves more to NLP analysis. The Web is for everyone, and people shouldn't be forced to read and write English to enjoy the latest advances in Web automation. Some languages are higher in the pecking order than others when software development is prioritized, and RDFa cannot level the playing field here. Suppose there's a use case that can be satisfactorily addressed by applying NLP heuristics to content for the top-tier languages. Even if there were an RDF mechanism for addressing the same use case without relying on natural language, software aimed for serving the top-tier languages would still do the NLP thing for the use case. No. There is no reason for most developers to prefer one over the other under the circumstances described. Clearly Google has an investment in text-harvesting in a bunch of languages. Equally clearly its competitors who are more sucessfeul in various languages (Yandex, Baidu, etc) have an investment in the technology they use. But developing a new indexing process, there is no a priori reason to favour NLP over some other technique that is also satisfactory, and if you happen to be interested in a global market, it makes sense to develop a system that can be more easily adapted, other things being equal. ... Instead of bearing the cost of developing a totally alternative technology stack for the other languages without benefiting from any spillover from the effort done for the top-tier languages, it makes more sense to invest the effort into building upon the reusable parts already developed for the top-tier languages. Except that it turns out that the re-usable parts of most search engines, for the general developer, are pretty limited. Whereas the re-usable parts of the RDF stack are numerous, available for many different platforms, from GPL open source to bespoke commercial closed-source and everything between. All this does not necessarily establish the case for using RDF in HTML, it is just meant to demonstrate that this particular case *against* doesn't seem to be established, to me. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
[whatwg] What RDF does Re: Trying to work out...
On Fri, 09 Jan 2009 12:54:08 +1100, Calogero Alex Baldacchino alex.baldacch...@email.it wrote: I admit I'm not very expert in RDF use, thus I have a few questions. Specifically, maybe I can guess the advantages when using the same (carefully modelled, and well-known) vocabulary/ies; but when two organizations develop their own vocabularies, similar yet different, to model the same kind of informations, is merging of data enough? Can a processor give more than a collection of triples, to be then interpreted basing on knowledge on the used vocabulary/ies? RDF consists of several parts. One of the key parts explains how to make an RDF vocabulary self-describing in terms of other vocabularies. I mean, I assume my tools can extract RDF(a) data from whatever document, but my query interface is based on my own vocabulary: when I merge informations from an external vocabulary, do I need to translate one vocabulary to the other (or at least to modify the query backend, so that certain curies are recognized as representing the same concepts - e.g. to tell my software that 'foaf:name' and 'ex:someone' are equivalent, for my purposes)? If so, merging data might be the minor part of the work I need to do, with respect to non-RDF(a) metadata (that is, I'd have tools to extract and merge data anyway, and once I translated external metadata to my format, I could use my own tools to merge data), specially if the same model is used both by mine and an external organization (therefore requiring an easier translation). If a vocabulary is described, then you can do an automated translation from one RDF vocabulary to another by using your original query based in your original vocabulary. This is one of the strengths of RDF. Thus, I'm thinking the most valuable benefit of using RDF/RDFa is the sureness that both parties are using the very same data model, despite the possible use of different vocabularies -- it seems to me that the concept of triples consisting of a subject, a predicate and an object is somehow similar to a many-to-many association in a database, whereas one might prefer a one-to-many approach - though, the former might be a natural choice to model data which are usually sparse, as in a document prose. I don't see the ananlogy, but yes, I think the big benefit is being able to ensure that you know the data model without knowing the vocabulary a priori - since this is sufficient to automate the process of merging data into your model. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Trying to work out the problems solved by RDFa
On Sat, 10 Jan 2009 06:41:10 +1100, Julian Reschke julian.resc...@gmx.de wrote: Tab Atkins Jr. wrote: *If* we want to support RDFa, why not add the attributes the way they are already named??? Because the issue is that we don't yet know if we want to support RDFa. That's the whole point of this thread. Nobody's given a useful problem statement yet, so we can't evaluate whether there's a problem we need to solve, or how we should solve it. For the record: I disagree with that. I have the impression that no matter how many problems are presented, the answer is going to be: not that stone -- fetch me another stone. There does appear to be some of this. I have no idea if that is just an impression or the truth. Hence my continued following of the thread. Alex's suggestion, while officially against spec, has the benefit of allowing RDFa supporters to sort out their use cases through experience. That's the back door into the spec, after all; you don't If something that is against the spec is acceptable, then it's *much* easier to just use the already defined attributes. Better breaking the spec by using new attributes then abusing existing ones. Indeed. I the data-* attributes had some reserved values, then one might expect people to invest in them on the scale that they have typically made RDF investments. But then there would be no need to change the attribute names at all (nor, for that matter, to put much effort into other attribute names following the design pattern. It just becomes another approach to namespaces with another centralisation process required). The question is what would convince the editors of the spec that there is in fact a use case for RDF in HTML which is what has led to the request to include RDFa (a form of RDF carefully designed to fit into HTML). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Synchronized play/seek of multiple audio elements?
On Thu, 19 Feb 2009 01:43:22 -, David Singer sin...@apple.com wrote: At 10:20 + 18/02/09, Ian Hickson wrote: On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. Yes. We felt it would be a major complication to the spec., and wanted to keep things simple for the first iteration. A problem arises for accessibility, when you extend this to video and need to synchronise captions / subtitles / audio descriptions, if they are not included in the original resource. There are various use cases for having the resource be stand-alone, and also for compound resources that HTML5 can pull together. At the FOMS discussion of accessibility, I believe the end result was an understanding (no formal resolution) that both approaches needed to be supported. This could be done in HTML5 by recommending something like a SMIL resource to deal with the second use case, shifting the implementation requirement to support (at least some of) SMIL for playing video. Or by adding some simple timing stuff to HTML itself, although that makes for backwards incompatibility even with current browsers having native video support. Or using SVG and pegging its timeline to the enclosing video, or ... These are not ready-made solutions, they are thoughts about possible approaches. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] time
On Mon, 09 Mar 2009 21:17:01 +0100, Tom Duhamel tom420.duha...@gmail.com wrote: Precise Date/Time My understanding is that the current protocol will only accept this format for a valid precise date: 2009-03-09 And this format for a valid precise time: 15:10 or 15:10:19 My opinion is that all the following dates are precise: 2009 2009-03 2009-03-09 I agree. These are also acceptable with ISO-8601 (although to be honest that spec accepts so many things it isn't always a good reference) and I think they are indeed useful things to be able to say about the future. Gregorian Calendar There have been requests that the time element accepts dates expressed in other calendars than Gregorian. This is not doable, although I do understand those who mentioned this, mostly about the Julian calendar. Julian for instance cannot give a precise date (we are not considering the fact that it was not precise enough) because it was based on some events in history, often the arrival of a new leader. For example, when Bush was elected in Nov 2000, we would have considered that year to be the new year 1. Thus Bush was elected in November 1, re-elected in November 5. Then Obama was elected in November 9 of the Bush era, which was also Novemember 1 of Obama era. This is not correct. (I am, as it happens, an historian who works at something else :) ). The Julian calendar only came into being in about 45BCE, and leap years were a bit odd until about 40 years later. For Roman calendars before the Julian calendar there is pretty good evidence, although they were named for the consuls elected that year. I.e. years were generally known by a pair of names rather than a number, but you can go back a long way with those names. Wikipedia is often mentioned as a use-case, but based on my own experience (I am not an historian or anything, so my use of Wikipedia for historical events is sporadic) they most usually convert Julian dates to the Gregorian calendar. Julius Caesar died in 14 BC, not 52 of the Julius era on the Julian calendar (or whatever date it would convert to). Nope, you are confusing your calendars here. The Gregorian and Julian calendars look the same, but 3 times every 400 years the Gregorian calendar skips a leap year that would have occurred in the Julian one. So Wikipedia dates are generally (but not always) Julian. What does happen is that Roman years were still named for consuls - the convention of using the supposed birth of Jesus as the year 1 came a few centuries later. So the 50 BC bit in Asterix would have been called the year of the consuls L. Aemilius Lepidus Paullus C. Claudius Marcellus at the time - and the year 100 AD would have been called something similar. The reason why we count back so many years is because we have very good records that make it easy to turn the named years into numbers (for people who didn't go to a Roman school and get beaten until they could recite the names of consuls for a few centuries), and can easily date lots of events (but not the birth of Jesus, which probably took place around 4-6 BC :) ). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] time
(I thnk this is a permathread for the moment, so posting it to HTML as well for reference. Is there an issue raised for this, or whatever the method /du jour/ for identifying questions to be dealt with is?) On Tue, 10 Mar 2009 01:36:33 +0100, Toby A Inkster m...@tobyinkster.co.uk wrote: It does seem to me to be a little foolhardy for HTML5 to be defining its own format for representing dates and times. ISO 8601 is already widely understood and implemented. Out of the box it is capable of representing any instant[1] between 1 BC and AD, including leap seconds and any other edge case you choose to think about. Why reinvent the wheel? In the same way that the W3C Date Time Format note did, it makes sense to profile ISO 8601 (which is monstrously big as well, and allows lots of different stuff). Indeed, referring to that (it is probably the most common format used in metadata communities, who are likely to be interested in using the element in the first place) would be a step forward. That format has some serious limitations for heavy metadata users. In particular for those who are producing information about historical objects, from British Parliamentary records to histories of pre-communist Russia or China to museum collections, the fact that it doesn't handle Julian dates is a big problem - albeit one that could be solved relatively simply in a couple of different ways. The other issue is the one of precision - while you can name a single year, which will deal with a lot of use cases there are a lot left out because the precision required is a period. Ranges are included in 8601, and making a range syntax that handled almost all the relevant use cases is pretty straightforward. Enabling these more complex use cases would resolve a lot of people's uneasiness over the limited utility of the current design. It would also make it easier to explain to communities who publish or hold large amounts of metadata how HTML 5 gives them a clear benefit. An alternative approach of course would be to enable RDFa, since using RDF it is already simple to deal with these use cases, and the people who have them very often ahve their data in an RDF-compatible form already. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] time
On Tue, 10 Mar 2009 18:03:37 +0100, David Singer sin...@apple.com wrote: At 3:22 +0100 10/03/09, Charles McCathieNevile wrote: That format has some serious limitations for heavy metadata users. In particular for those who are producing information about historical objects, from British Parliamentary records to histories of pre-communist Russia or China to museum collections, the fact that it doesn't handle Julian dates is a big problem - albeit one that could be solved relatively simply in a couple of different ways. The trouble is, that opens a large can of worms. Once we step out of the Gregorian calendar, we'll get questions about various other calendar systems (e.g. Roman ab urbe condita http://en.wikipedia.org/wiki/Ab_urbe_condita, Byzantine Indiction cycles http://en.wikipedia.org/wiki/Indiction, and any number of other calendar systems from history and in current use). Then, of course, are the systems with a different 'year' (e.g. lunar rather than solar). And if we were to introduce a 'calendar system designator', we'd have to talk about how one converted/normalized. I'd rather have the historical pages say In the 4th year of the first Indiction cycle of the second reign of the Emperor Justinian called the golden-nosed, in the 3rd day following the nones of August, at the hour of dawn in the city of Chrysopolis (and then they give the Gregorian translation, e.g. 6am on the 12th of August 707 CE). Indeed. That's one of the ways it can be done. IMHO it meets a huge set of the possible use cases. And it has the sort of simplicity that tends to be the defining characteristic of the best of HTML5. (Well, parsing isn't simple and is clearly part of the best of, but I am sure you get my drift...) The other issue is the one of precision - while you can name a single year, which will deal with a lot of use cases there are a lot left out because the precision required is a period. Ranges are included in 8601, and making a range syntax that handled almost all the relevant use cases is pretty straightforward. Adding a range construct to 8601, or having a range construct ourselves using 2 8601 dates, seems like something we could ask for or do. Yep. Using a slash, as ISO 8601 does, strikes me as pretty simple and gives us compatibility. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] time
application that can create timelines from marked up events in a page; - Date based news searching applications (e.g. searching for news from a particular time period). Or objects, or people, or events... * Investigation of how imprecise dates affect the ability to import such events into a calendar. e.g. The Sydney Royal Easter show scheduled for 2009-04, and takes place over a period of a few weeks in the month. Is it enough to simply say: time datetime=2009-049–22 April 2009/time Or would it be better to give the precise date range, as time datetime=2009-04-099/time–time datetime=2009-04- April, 2009/time Or would supporting a range directly in the datetime field support this better: time datetime=2009-04-09/2009-04-229–22 April 2009/time It would be better to have it as a range, is the clear conclusion from working in this area. The event does not take place over April, and it doesn't happen on the start and end day. My calendar lists what country I will be in, and those are date ranges - nothing else is useful. Conferences I go to require a date range if they run for more than one day, in order to process them intelligently. People's lives are measured as a date range - in some cases (e.g. Julius Caesar) they can be measured to a given day, in some cases, a year, and in some cases, one terminal of the range is unknown. Note that this introduces a complication. What to do when comparing an unknown date as one terminal of a range (Centurion Crismus Bonus, ??/-0042) to an open-ended range (the period before the introduction of the Gregorian calendar in anglophone North America, .../1752), if anything. Another case for an imprecise date might be: ptime2009/time is The International Year of Astronomy./p For this, we would need to understand what real benefit consuming applications would gain from that. It's not really a date that someone would want to import directly into their calendar. WHy on earth not? I have imported such things into calendars before. There is a lot of money spent on calendars explaining what chinese year we are in, or what holidays and festivals are expected, and some of this is what did the UN or the CWA or the Secret Cabal or the HR department declare this year to be? But understanding what other potential applications, such as those mentioned above, might want to do with it would be useful. Understanding the universe would be useful. But it turns out that we ship software (and ships, and spacecraft) even before we have understood the grand unified field theory. Understanding *enough* to justify a decision to do something (and that is a very subjective judgement) is sufficient. In this case, there is a lot of practical experience of calendaring. Many people made a lot of money from it in the late 90s, for example. It would seem that proposing to take a small, conservative and widely-used part of a common standard practice, we could easily enough discover if there are noted problems we should note and plan to avoid. What advantage is there for authors and consumers by *not* extending the range of dates that can be described with time ? That's the wrong question to ask because it places the burdon of proof on the wrong side. But by not addressing every possible little use case under the sun, we keep the language simplified and easier for authors to learn and use, and we can focus on really optimising for the top ~80-90% of the use cases, without spending a disproportionate amount of time trying to optimise for the remaining ~10% of edge cases too. Actually, both questions are worth aking. Because if it turns out that for 1% incremental effort, we can effectively optimise for 99% of cases instead of 80% (I am making these figures up, just as you are) then it would appear worthwhile. Satisfying the demands of the braying public isn't a design principle. It is one of the things that W3C specs try to do in order to get the consensus that makes them respected specifications, and where the effort required, and the risk of making mistakes, are minimal (for example, because you are copying stuff that is used every day in practice by lots of people all over the world, rather than inventing something new). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Please review use cases relating to embedding micro-data in text/html
On Thu, 23 Apr 2009 22:46:09 +0200, Ian Hickson i...@hixie.ch wrote: USE CASE: Allow users to maintain bibliographies or otherwise keep track of sources of quotes or references. SCENARIOS: ... * Chaals could improve the Opera intranet if he had a mechanism for identifying the original source of various parts of a page. (why?) Because the page is put together by various different people (or processes), so knowing who is responsible for some bit that needs work is important in contacting the right person faster. (This isn't specific to Opera's intranet, of course. That happens to be the one I use most). REQUIREMENTS: * Machine-readable bibliographic information shouldn't be on a separate page than human-readable bibliographic information. * The information should be convertible into a dedicated form (RDF, JSON, XML, BibTex) in a consistent manner, so that tools that use this information separate from the pages on which it is found have a standard way of conveying the information. cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Please review use cases relating to embedding micro-data in text/html
On Thu, 23 Apr 2009 22:46:09 +0200, Ian Hickson i...@hixie.ch wrote: * Shouldn't require the consumer to write XSLT or server-side code to process the annotated data. Does process here mean extract from the page, or something more? cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Please review use cases relating to embedding micro-data in text/html
On Fri, 24 Apr 2009 05:53:09 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 23 Apr 2009, Manu Sporny wrote: I've looked over the list a couple of times and it's a good introduction to the problem space. It's not really intended to be an introduction, so much as a complete list of use cases that people want the spec to cover. ... Oh. Then I think it is probably doomed to be incomplete - users not only do concrete things, but they do lots of different concrete things. This is possibly (probably?) a large enough set from which to derive general principles and clear goals. From the point of view of the HTML5 effort, what is needed is use cases, scenarios, and requirements, that don't in any way imply a particular solution, as in the list I posted, so that solutions can be evaluated. ... So how do the solutions get proposed, or do you already have a candidate list you have selected? What's the process here? cheers chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
[whatwg] alt text...
cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] converting word (was code attributes
On Thu, 30 Apr 2009 13:25:17 +0200, Kristof Zelechovski giecr...@stegny.2a.pl wrote: Automatic conversion from Microsoft Word to HTML is doomed to fail because the document models and the requirements are different. The best you can get is a tree of DIVs and SPANs with Word- specific classes. Anything better needs a serious and thoughtful remake by the editor. This is an oversimplification to the point of being misleading. There are many ways to use Word, and many people and organisations with haf a clue use it in such a way that automatic conversion can be relatively easily used to generate highly semantically rich and valid markup - much better than the sort of tripe one typically finds on the Web today. Word enabled the clear semantic markup of documents before HTML even existed, and people who use it like that are in a good position to produce HTML that is much better quality than most developers come up with. It also enables presentation-driven markup to be converted automatically to make the underlying semantics explicit (something that virtually no HTML tool outside those which convert from another input format manages to do). This stuff is not rocket science, either. It is the sort of thing that was routine more than a decade ago when people started to use HTML as well as, or instead of, Word and similar formats. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Clickjacking and CSRF
On Thu, 16 Jul 2009 03:48:41 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Jul 15, 2009 at 9:24 PM, Jonas Sickingjo...@sicking.cc wrote: Note that Content Security Policies[1] can be used to deal with clickjacking. So far we've gotten a lot of positive feedback to CSP and are in progress of implementing it in firefox. So it's a possible solution to this. Is Mozilla planning to run CSP through a usual standards body like the W3C, either before or after implementation? If you plan to standardize it after implementation, why not before instead? CSP looks really exciting, but I'm not clear on whether or when it will be standardized -- I've heard talk of implementing it, but not of standardizing it. Opera has been actively following up this problem with various browser vendors (in particular) in the hopes of at least getting us all together in a useful forum. If you're curious, Sigbjørn is our lead for this effort. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] HTML5: has input device: use motion detection been included?
Hi Jonathon, On Mon, 03 Aug 2009 10:27:02 -0400, ~:'' ありがとうございました j.chetw...@btinternet.com wrote: HTML5: has input device: use motion detection been included? many laptops, mobiles and other devices come with cameras at this time. motion detection offers some potential accessibility benefits, and the opportunity to appear and play in game spaces. This is among the things that the Device API group is expected to cover with new APIs for such capabilities. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] HTML5: has input device: use motion detection been included?
On Mon, 03 Aug 2009 12:25:58 -0400, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Chaals, Jonathan, Input devices are currently not in the DAP charter. http://www.w3.org/2009/05/DeviceAPICharter.html They are not in the list of deliverables (which is a high-priority set of things that people are already working on). They are, as I understand it, well within the scope of the group. So it would take a draft, an editor, and presumably use cases and interest from implementors, before the group might add them to the deliverables. I am not sure whether the charter is to change soon, although it should be possible, I think. Yes, I think that we agree on the way such work would happen, and that it is certainly possible in the scope of that group. cheers Chaals Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Charles McCathieNevile Sent: Monday, August 03, 2009 6:05 PM To: ~:'' ありがとうございました; wha...@whatwg.org; public-weba...@w3.org Cc: Doug Schepers; i...@hixie.ch Subject: Re: [whatwg] HTML5: has input device: use motion detection been included? Hi Jonathon, On Mon, 03 Aug 2009 10:27:02 -0400, ~:'' ありがとうございました j.chetw...@btinternet.com wrote: HTML5: has input device: use motion detection been included? many laptops, mobiles and other devices come with cameras at this time. motion detection offers some potential accessibility benefits, and the opportunity to appear and play in game spaces. This is among the things that the Device API group is expected to cover with new APIs for such capabilities. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Test results for xmlns:foo attribute preservation across all browsers
On Thu, 06 Aug 2009 15:12:07 -0400, Manu Sporny mspo...@digitalbazaar.com wrote: The test ensures that attributes originating in the markup of an HTML4 document are preserved by the HTML parser and are preserved in the DOM. [...] http://html5.digitalbazaar.com/tests/xmlns-attribute-test.html We have verified that xmlns:-style attributes are preserved in the following browsers: Also works in the latest Opera 10 Beta 2 plus Unite snapshot. Opera 10 - Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00 (yeah, the UA string is like that because important websites with browser sniffing check version numbers, but only the first digit. I.e. they can't count to ten yet). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Test results for xmlns:foo attribute preservation across all browsers
On Mon, 10 Aug 2009 11:37:15 -0400, Bil Corry b...@corry.biz wrote: Charles McCathieNevile wrote on 8/6/2009 2:24 PM: On Thu, 06 Aug 2009 15:12:07 -0400, Manu Sporny mspo...@digitalbazaar.com wrote: The test ensures that attributes originating in the markup of an HTML4 document are preserved by the HTML parser and are preserved in the DOM. [...] http://html5.digitalbazaar.com/tests/xmlns-attribute-test.html We have verified that xmlns:-style attributes are preserved in the following browsers: Also works in the latest Opera 10 Beta 2 plus Unite snapshot. Opera 10 - Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00 (yeah, the UA string is like that because important websites with browser sniffing check version numbers, but only the first digit. I.e. they can't count to ten yet). The issue now is that websites that can't count to ten will not realize it because their site continues to function properly. Well, they won't realise it through seeing their site break in Opera. And for sites that can count to ten, well, you've broken them too. My own sniffer reports version 9.80 for the above UA string whereas if it was still in the normal Opera format, it would correctly report version 10.00. I'm glad you are smarter than the average bear, and I am sorry that we don't have a reward for that. But in practice, we are forced to decide whether it is better to catch the attention of web designers by making their site not work (with the incidental cost of catching the attention of users who discover that the site doesn't work), or by some other means. Our experience suggests that the former is simply not effective - and this is one of the reasons WHAT-WG began - to deal with the Web in practice, and look for ways to improve HTML that didn't require browsers to suddenly stop working for reasons that, *to the user* are mystifying and cause them to blame the browser. So yeah, this is clearly a sub-optimal situation and we want to change it. That alone won't make the change - which is why Opera pays people specifically to go around fixing web sites, code libraries, etc. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Alt attribute for video and audio
On Mon, 10 Aug 2009 10:42:36 -0400, Remco remc...@gmail.com wrote: On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. Must at least means that if you can't do it right, here is how to get it only half-wrong (i.e. not good practice, but enough to be useful anyway) title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you ant to provide an alternative, then I suggest that is not a good one. It is a description of the video, rather than a replacement. An alternative is something more like As a ball falls, every second it goes 9.8m/s faster than it was going a second before, because gravity makes it accelerate. In practice, effects such as drag (wind resistance) will affect the actual speed - and the value of 9.8 is specific to the average sea-level of earth - it depends on the mass of the earth and the ball. If you already have this in the preceeding or following text, something like Benjamin's examples, then the job is done and repeating it in alt is redundant and bad practice. To be clear, your example text is better than nothing - and in accesibility that is often as good as it gets :( But there's value to explaining how to do things better - and this particular issue is something that has gathered a *huge* amount of discussion and explanation over the last decade and a half. [snip] To be clear, I think that the existing options for video in HTML5 are better than anything we would gain by adding an alt attribute. The only value I can see in adding one is that some people who are careful enough to use it with images will also use it effectively even if they will do nothing better - but this would require careful large-scale study of authors *as they work* to verify, and I doubt that is going to be done. -- Benjamin Hawkes-Lewis One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. The question now is: why would we need both figure and aria-describedby? Because many designers will not put sufficiently complete text explanations of everything in the ordinary flow of a document. This is actually a valuable accessibility practice - the large number of people who have difficulty reading can often find that their ability to use content is significantly reduced by the presence of large blocks of text. This is something that most usability engineers and communication experts understand instinctively, actually. So we need some way that allows for more than one presentation scenario. Either we ask people to make multiple pages (something that is well-known to suffer from the out of sight out of mind problem, or we provide ways to manage more information in a single page (which also suffers from the problem, but it is believed less so. I don't know how many careful studies have been done of this, if any). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] SVG: Accessible Forms
On Wed, 02 Sep 2009 15:38:00 +0600, ~:'' ありがとうございました j.chetw...@btinternet.com wrote: Chaals, thanks for yet another well considered and easy-to-read response*! your comments around ARIA and SVG are noted. however you fail to address the central issue, which as Filipe Sanches wrote me in a private email, and which I believe correctly states the case: Implementing it is not trivial and that is why this kind of thing should be available as a general module. Preferably as part of the spec in order to get it into every UA. my query was intended to address this issue in particular. ie as to why whereas accessible html forms had been around for about a decade, accessible svg forms remain extremely hard to implement. Because for SVG there was nothing formal like ARIA until now. There was the idea foreshadowed in the svg-access note[1] a decade ago of using metadata to tag objects - this dates from the very early days of what became ARIA, in discussions with Lisa Seeman of UBAccess and Rich Schwerdtfeger of IBM who followed this work through the spec editing process that eventually got us ARIA. There was also work on using Xforms, for example the experimental work of X-smiles and the work of Sebastian Schnitzenbaumer. Unfortunately that never got traction for a variety of reasons (not least the failure of XHTML, meaning that little effort was made to develop better tools for the public to create content). Effectively this was because there were not enough people working actively on making SVG accessible - so we are not much further ahead than we were 8 years ago. Given the new and renewed interest in SVG by people who understand accessibility, I expect to see much more progress in the next 2 years. SVG1.1 has now been implemented by many UA and browsers, but still miss this vital user functionality. Yes. So we are only now arriving at the stage of making this really possible. With ARIA in the spec, and with at least Opera working on implementation, it should become possible. There is a structural fault in the W3C process, and that is why process are copied into this thread. I think that should be a seperate thread - fixing the process and fixing the SVG problem are things that need to be done by different people. Mixing the two is likely to lead to more discussion about process and less action on anything :( cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
