| 02:03 | <TabAtkins> | Hixie: In "Selecting names when defining vocabularies"'s list of properties that appear in the example at the bottom, you say "This example has one item with two types...". I only see the one type, though. |
| 02:04 | <Hixie> | fixed thanks |
| 02:13 | <TabAtkins> | What *possible* times would an *element* be needed for customization where a class wouldn't cut it? |
| 02:13 | <TabAtkins> | That... that just doesn't make sense. <div class="foo"></div> is functionally identical to <foo></foo> for purposes of extending the language. The only difference is that the first one works right now and is accepted by everyone. |
| 02:15 | <Hixie> | chapter 3 of http://www.rfc-editor.org/rfc/rfc5434.txt seems relevant |
| 02:35 | <othermaciej> | TabAtkins: I looked at some SVG files where Inkscape adds elements and not just attributes for its design-time metadata |
| 02:35 | <othermaciej> | TabAtkins: it does seem to use elements for some things |
| 02:36 | <othermaciej> | TabAtkins: it seems to be in cases where there are logical "objects" with a bunch of key-value pairs, where in principle you may have more than one such object per document or per affected parent element |
| 02:36 | <othermaciej> | TabAtkins: so you can't just add attributes to the affected element |
| 02:36 | <othermaciej> | TabAtkins: or at least, that would be awkward |
| 02:36 | <othermaciej> | you have to use a semantically null, non-rendering element |
| 02:36 | <othermaciej> | <div> is not great because, even though it has no semantics, it renders by default |
| 02:37 | <othermaciej> | <meta> might work, though only for things that have document-wide scope |
| 02:41 | TabAtkins | is sorry, was off making dinner. |
| 02:42 | <TabAtkins> | That makes sense, but we have tools for that now. |
| 02:42 | <TabAtkins> | Microdata is the obvious candidate. |
| 02:43 | <TabAtkins> | Plus the aforementioned just-use-a-comment suggestion. |
| 02:43 | <TabAtkins> | Hell, embed xml in your comment or whatever. If you have the source, that's more than adequate. |
| 02:43 | <TabAtkins> | And it doesn't mess with what anyone else sees, as intended. |
| 02:46 | <TabAtkins> | Though I see how comments would fail the "must roundtrip through editting tools" requirement. |
| 02:51 | <othermaciej> | yes, I think comments fail due to round-tripping |
| 02:51 | <othermaciej> | microdata could work in place of data-* attributes, but I think it has the same issue as RDFa of introducing overconstraining model structure |
| 02:52 | <othermaciej> | microdata doesn't by itself provide a solution to the kinds of use cases that would call for an element with null semantics and no rendering |
| 02:53 | <othermaciej> | (and which can be placed anywhere) |
| 02:54 | <othermaciej> | like if your editor wants to represent multiple "viewports" (where you might have different size/shape windows zooming into different parts of the image), there is likely no existing element in the document to associate each one with |
| 02:54 | <othermaciej> | and it's hard to express as a single set of key-value pairs on the root element |
| 02:55 | <othermaciej> | I suppose you could do it with sufficient extra levels of indirection, it would just be messy |
| 02:57 | <othermaciej> | OK, microdata can do it, using <meta itemprop itemscope> |
| 02:59 | <othermaciej> | but requiring a separate element for each property would be a significant burden, I think |
| 03:00 | <othermaciej> | it would be nice it you could add properties directly to the itemscope element with attributes of some kind, maybe something analogous to data-* attributes |
| 03:10 | <Hixie> | can't inkscape just use xml as its internal format, like, well, like it does already? |
| 03:13 | <othermaciej> | I think Inkscape is being used as a stand-in for HTML editing tools that may similarly want to record design-time information |
| 03:14 | <othermaciej> | (including hypothetical future SVG-in-HTML tools) |
| 03:14 | <othermaciej> | at least that's how I am thinking about it |
| 03:16 | <othermaciej> | (but it provides more of a concrete example than a purely hypothetical example) |
| 03:25 | <TabAtkins> | It seems like we're talking about tools here, so I'm not sure why lots of <meta>s is so bad. It would be inconvenient when hand-authoring, but that's not the use-case we're talking about. |
| 03:26 | <TabAtkins> | It's a bit weighty, but not horribly so. |
| 03:27 | <TabAtkins> | And with a lot of properties that are grouped, you can wrap them in a <div itemscope itemtype="foo" hidden></div> to save on the per-item weight. |
| 03:32 | <Hixie> | othermaciej: can't they use xhtml, then? or does the on-the-wire format have to have this stuff? it seems bad for bandwidth to be encouraging people to export this proprietary stuff onto their site |
| 05:29 | <boblet> | On a weblog homepage showing excerpts of recent articles (wrapped in <article>), these shouldn’t be inside a parent <article>, should they (<section> instead, right?) |
| 07:33 | <annevk42> | Hixie, wouldn't itemScope etc. be more consistent? |
| 07:51 | <MikeSmith> | Hixie: I thought you had mentioned dropping the predefined vocabularies |
| 07:52 | <annevk42> | are they not dropped? |
| 07:54 | annevk42 | doesn't see them |
| 07:54 | <MikeSmith> | diff seems to just show that they moved |
| 07:57 | <annevk42> | I think it shows they are no longer in HTML5 but still in the source doc |
| 07:58 | <annevk42> | itemtype doesn't even allow predefined vocabs |
| 07:59 | <MikeSmith> | annevk42: yeah, OK, I see now |
| 08:00 | <othermaciej> | well, there's one issue we can resolve |
| 08:01 | <annevk42> | I guess the idea is to define org.w3.vcard or some such |
| 17:08 | <Dashiva> | http://www.jgc.org/blog/2009/09/javascript-must-die.html |
| 17:13 | <miketaylr> | deprecate javascript, that's cute |
| 17:17 | <gsnedders> | I think that'll have about as much effect as deprecating presentational markup has had. |
| 17:36 | <othermaciej> | there's a lot of sloppy thinking and/or sloppy communication in those slides |
| 17:50 | <Dashiva> | Oh, poor RDFa. It only supports RDF. |