Re: [whatwg] XPath-like API
On Mon, 13 Nov 2006, Carlos OKieffe wrote: > > Are there any plans to attach an XPath like API to this HTML spec? I > think it may be helpful for parsing elements by attributes like > /[EMAIL PROTECTED]'alternate']. The W3C WebAPI working group is working on something like this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] XPath-like API
Are there any plans to attach an XPath like API to this HTML spec? I think it may be helpful for parsing elements by attributes like /[EMAIL PROTECTED]'alternate'].
[whatwg] The WHATWG Blog and FAQ
Hi Everyone, *The WHATWG Blog* A new community blog has been created [1]. The aim of the blog is to keep the public informed about the development of (X)HTML 5, the WHATWG, and related topics, and get feedback from those who do not wish to participate directly in the mailing list. At present, we're going to allow anyone who has contributed to the spec to register and write a post. You can write whatever you like as long as it's on topic. But remember, when you write a post, you'll be seen as representing the WHATWG and if you write something bad, that reflects badly on the whole community. Basically, use your common sense and keep it polite. A select few of us will act as moderators just to take action when necessary. Any wildly off-topic or extremely inappropriate posts will be deleted, but hopefully we won't need to delete anything (except spam). We'll see how this system goes for now, but if it gets out of hand we'll have to make other arrangements. If you want to do something about the blog design, create a WordPress template and send it to Hixie. *The FAQ* Based on the feedback received [2] from the recent announcements [3], we're also creating an FAQ [4]. Any suggestions for questions or answers are welcome. Just send them to the list with "[FAQ]" in the subject line. I'll be the editor of the FAQ and will respond to all of those posts (where necessary). [1] http://blog.whatwg.org/ [2] http://del.icio.us/lachlan.hunt/WHATWG [3] http://lachy.id.au/log/2006/11/future-of-html [4] http://blog.whatwg.org/faq/ -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Mon, 13 Nov 2006 22:30:13 +0600, Jeff Seager <[EMAIL PROTECTED]> wrote: > After reflecting on your points and others, Alexey, I do expect more of > a caption than I expect of a simple attribute. Most importantly, I > expect it to be visible by default if I have a visible picture. For that > reason, I agree now with those who suggest a CAPTION (or LEGEND) > element, rather than an attribute. I totally agree with you here. I believe HTML should have an element for every attribute intended to hold human-readable text. A raw idea can go like this: ... Here, holds a value which should be treated the same way like the title attribute on , except that it can contain nested markup. This would be useful for all attributes defined as %Text in HTML -- in HTML4, these are ABBR, ALT, LABEL, STANDBY, SUMMARY, TITLE. However, doing a full straightforward solution like this may be bad for backward compatibility, especially in the case of ALT. But the idea is: whenever we write an attribute of type %Text, we want text with markup, so an element instead of attribute is needed. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] Still beating the drawString() dead horse...
Hi, I have tried to sum up the requirements for CanvasRenderingContext2D.drawString() at http://rhino-canvas.sf.net/www/drawstring.html The page contains an API proposal based on the Font/TextStyle object approach that meets all those requirements, and also some motivation why I have implemented this approach and not one of the alternatives discussed here. Best regards, Stefan
[whatwg] nav element attributes
Hi,I'm quite pleased to see a nav element being proposed. It will make things much easier for assistive technologies and potential improvements to search engine listings, as well as having more meaning than an unordered list.I saw that there are no attributes beyond the standard HTMLElement ones, but I think this element could be made even more useful by providing an optional attribute called something like 'type' or 'level' that lets the author describe whether this particular part of navigation is the top-level navigation, the secondary navigation, page-related navigation, etc. In my experience, these are either split out or nested to improve the user experience.Another useful thing would be to allow nav elements to be nested within nav elements so that a sitemap could be described.Is nav still in development?Dawn Budge
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey notes: > With CSS3 it's possible to display the value of "title" attribute in the > visual flow. For older UAs a JS implementation is trivial. I didn't know that about CSS3, and that would be a good solution except where the end user has specified a local stylesheet to override the designer's style specs. Some users don't allow or don't recognize javascript, either, so when I use script I have to allow for alternative presentation. The drop-down menu I'm using degrades to an unordered list of links without javascript, for example. Considering all that, I still think captioning rightfully belongs in the HTML/XHTML semantic structure. After reflecting on your points and others, Alexey, I do expect more of a caption than I expect of a simple attribute. Most importantly, I expect it to be visible by default if I have a visible picture. For that reason, I agree now with those who suggest a CAPTION (or LEGEND) element, rather than an attribute. I especially like Matthew Paul Thomas' thinking on this: > I suggest that this element behave in the opposite way from alt=: > whereas alt= should be presented only if the image itself is *not* > presented, the caption element should be presented only if the image > itself *is* presented. Otherwise there would be the same problem with > non-sequiturs in non-visual media as there is with descriptive alt=. Simple, elegant, functional ... so please, somebody shoot holes in this and make it an even better idea. I apologize if I've gone over old ground on this. I'm new to this list, and others have indicated that this has been discussed before. Has it been decided, though? To me, it seems a very basic and urgent need in the HTML/XHTML specs. Jeff Seager West Virginia Division of Rehabilitation Services
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey Feldgendler wrote: > On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon <[EMAIL PROTECTED]> > wrote: > >> Couldn't we extend the element to work for images as well as form >> elements? The for attribute would provide the explicit link to the image >> that would take the label's contents out-of-stream for screen readers, >> and would likewise (with some CSS changes, I suppose) allow the caption >> to be >> positioned correctly relative to the image for visual browsers. > > Today's browsers seem to have problems about outside of . I'm not aware of the problem. The worst that seems to happen when you use a element with an is that the element becomes just a stylable inline element. That would seem to be the best fallback styling we can hope for in a caption/label. If you're referring to focus passing, WF2 already places platform-specific limits on user agents that prevent focus passing in certain situations. Because most platforms don't give an image focus when you click on it's label (or caption), WF2 would indirectly define as not passing focus in that situation. I was actually thinking of something like this: | | | | Image caption text. | | ...Where fallback content is ignored by : | | | | | | | | Image caption text. | | | | So, in the above, the UA would treat the second example as if it where the first.
Re: [whatwg] Relationship to Charmod and Charmod Norm
On Nov 11, 2006, at 15:35, Henri Sivonen wrote: encodings that "everyone" supports. A passable practical definition could be the intersection of the IANA-registered encodings supported by IE6, Opera 9, Firefox 2.0, Safari 2.0.x, Sun JDK 1.4.2 and Python 2.4. For the record, the following is the intersection of the IANA- registered encodings supported by JDK 1.4.2_08 (Sun Solaris Sparc; other vendors such as Apple and IBM add encodings) and Python 2.4.3. The list does not change when intersected by the encodings supported by Opera 9 and Firefox 2. (Safari doesn't list all the encodings it supports in the UI and I don't have IE.) Big5 Big5-HKSCS EUC-JP EUC-KR GB18030 GBK ISO-2022-JP ISO-2022-KR ISO-8859-1 ISO-8859-13 ISO-8859-15 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-9 KOI8-R Shift_JIS TIS-620 US-ASCII UTF-8 windows-1250 windows-1251 windows-1252 windows-1253 windows-1254 windows-1255 windows-1256 windows-1257 windows-1258 UTF-16 UTF-16BE UTF-16LE (Method: A list was extracted from java.nio.charset.Charset.availableCharsets(), the x- entries were removed and the rest were fed to Python codecs.getdecoder().) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Nov 9, 2006, at 11:57 AM, Jeff Seager wrote: ... Among all literate people, I believe there is a longstanding expectation that pictures are accompanied by meaningful descriptions (usually below the image, but often to one side). The absence of image captioning seems to me to be an oversight, or at least an overlooked possibility, in the HTML/XHTML standards. As I was taught, a proper caption should not describe the picture (as ALT should), but complement or elucidate the information presented by the graphic. alt= should not describe a picture, but rather be a text alternative, because a description is a non-sequitur in a non-visual medium. (Unless, perhaps, the UA precedes it with the phrase "And if you weren't so blind you could see an image here that shows...":-) Anyway, I support the idea of a caption *element* to accompany images. This would have two benefits over an attribute: 1. It could contain markup, which an attribute cannot. 2. With a for= attribute, it could apply to an image elsewhere in the document, which would be useful for the print medium. For example: Top left: The class of 2006. Top right: Simone with her parents on graduation day. (For the screen medium, ideally UAs would place a caption adjacent to the relevant image, regardless of where the caption occurred in the document.) I suggest that this element behave in the opposite way from alt=: whereas alt= should be presented only if the image itself is *not* presented, the caption element should be presented only if the image itself *is* presented. Otherwise there would be the same problem with non-sequiturs in non-visual media as there is with descriptive alt=. -- Matthew Paul Thomas http://mpt.net.nz/