Re: [whatwg] Microdata DOM API issues
On Sat, 14 Nov 2009 00:34:12 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 13, 2009 at 5:14 PM, Philip Jägenstedt phil...@opera.com wrote: The itemref mechanism allows creating arbitrary graphs of items, rather than the tree of items that is the intended microdata model (right?). Even though my default reaction to graphs is oh cool, for microdata when the domain model is a graph you should probably just represent it with a level of indirection (RDF). Options: 1. patch the algorithms which can go into recursion 2. patch http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items to first check if an itemref'd property creates a loop before adding it to candidates 3. ? I think I prefer 2. Looping in data-graphs is often useful, so I'm not sure I want to throw it out generally. Your statement in the first paragraph I'm quoting, though, says that you'd rather leave loops to be defined in the vocabulary itself? So loops would be done by, frex, itemprop'ing a link to the other element rather than itemref'ing the other element directly? Yes, that's basically what I'm saying. One option is to simply use microdata such that the RDF you extract is the graph you want (it will probably look quite ugly though). Another is always referencing subitems by a mechanism other than refid. For example, in the MusicBrainz XML webservice when an artist contains a release which itself references artists (e.g. as the producer), a stub item is used with only artist name and id, rather than including all information recursively. In microdata I would do: section itemscope itemtype=http://musicbrainz.org/artist/; itemid=http://musicbrainz.org/artist/4d5447d7-c61c-4120-ba1b-d7f471d385b9; h1 itemprop=nameJohn Lennon/h1 section h1Releases/h1 section itemprop=release itemscope itemtype=http://musicbrainz.org/release/; itemid=http://musicbrainz.org/release/f237e6a0-4b0e-4722-8172-66f4930198bc; h1Imagine/h1 Producer: span itemprop=producer itemscope itemtype=http://musicbrainz.org/artist/; itemid=http://musicbrainz.org/artist/e7b587f7-e678-47c1-81dd-e7bb7855b0f9; span itemprop=namePhil Spector/span/span /section /section /section Even if John Lennon were the producer here, you don't get any looping in the microdata itself. If you want to know everything about the producer, you should just follow the itemid... I haven't looked that much at the RDF extraction algorithm yet, but I think this example might even create the proper graph with loops if the producer were John Lennon. That would probably be fine, and is compatible with a tree-based data model like JSON. Vocabs should know when loops are permissible/desirable for themselves. I agree, I don't see that we have a problem here. -- Philip Jägenstedt Opera Software
Re: [whatwg] rp is a styling tag and has no semantic function
Nikita Popov pri...@ni-po.com:
Screen-readers are yet another problem: I'm not sure, what's better:
ka-n-ka-n-ji-ji or
ka-n-bracketopen-ka-n-bracketclose-ji-bracketopen-ji-bracketclose. I
think the first one is even better, because the text is only duplicated
and the reader mustn't read the brackets, too. (This is for
screen-readers not supporting ruby. The ones that support it can then
handle it by only reading out the rt, as you proposed. [Though you need
to consider the problem above.])
I don't use screen readers often, but I'd like to note that '(' is a
parenthesis not a bracket.
so it should be 'open parenthesis' and 'closed parenthesis' respectively.
http://en.wikipedia.org/wiki/Bracket#Parentheses_.28_.29
screen readers should have a way of handling parentheticals which
doesn't involve reading them as individual characters.
I believe you're imaging problems that don't exist and therefore
potentially creating problems that aren't necessary
Re: [whatwg] validationMessage
So... trying to do anything like this is a disaster. But it sounds like the API is *trying* to handle the problem described below. I'm not sure it does (and suspect in fact that it doesn't). === implementation experience: GMail with a composed but unsent message will toss up a dialog if you try to leave the page. In the MicroB browser on the N900 we provide localized Yes/No buttons instead of OK/Cancel buttons (because our UI specifiers don't use browser user and don't care about GMail). As a result we get lots of bugs complaining about this behavior. https://bugs.maemo.org/show_bug.cgi?id=5130 there are probably 20 or so internal bugs for this issue. I'm pretty sure that makes it one of our highest reported bugs. In short, there's no way to get any of this right. Google apparently does expect localized buttons https://bugs.maemo.org/show_bug.cgi?id=5704 but in some cases the buttons they expect are not the labels they want. We've had reports where the gmail instructions mention OK/Cancel and the user had localized (Yes/No) buttons . === The problem is that there's basically no way to properly frame such a thing. If the user agent is using Portuguese but the Browser Content is using English, then you're going to have to have something where there's a language mix in the content area. Any transition here will be rough. Trying to assume how the string is formatted or trying to guess which strings describe the given buttons/actions by doing parsing is going to fail. OTOH, a User Agent could e.g. stick an error case into an information banner (typically the thing at the top of the page which is not part of the content area).
Re: [whatwg] Canvas.cloneNode()
On Fri, 30 Oct 2009 12:03:46 -0400, OmegaJunior omegajun...@omegajunior.net wrote: Greetings, Since Last Call was announced and I just ran into this problem, hereby this question: If an image is drawn on a Canvas element, and subsequently the javascript function cloneNode(true) is executed for that element, should the clone include a copy of the source canvas image, or should it show an empty space? I think it'd be cool if the clone showed the image. But, I'm pretty sure cloneNode(true) is just supposed to create a new canvas element with the same attributes and childNodes as the original. It's not supposed to copy everything that's going on with the element being copied. There are some exceptions with state for certain elements. Perhaps that can happen with canvas too. -- Michael
Re: [whatwg] Do we really need history.clearState()?
On Sat, Nov 14, 2009 at 5:23 PM, timeless timel...@gmail.com wrote: what if pushState returned a value which could be passed to clearState? I'm not sure how this would work. What would clearState do with that value? (i can't find clearState in http://www.whatwg.org/specs/web-apps/current-work/#dom-history-pushstate Hixie removed it a few days ago. -Justin
