[whatwg] request for clarification: aside, figure
I don't think the spec is clear enough defining these two elements from an author's perspective. The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. The figure element represents some flow content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. What is the difference between a figure that has no caption and an aside? Both seem to be connected in some way with the main content around it, but can be considered separate/ may be moved. Common-sense suggests that a figure is usually an illustration/ diagram/ picture, but doesn't have to be (the spec gives an example of the poem Jabberwocky marked up as a figure). So If I have a magazine-style pullquote, is that a figure or an aside (or neither)? For example, in the middle of a fictional interview about markup, I might want to pull out a quote and citation: Do I write aside blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote citeIan Hickson/cite /aside Or figure blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote legendIan Hickson/cite /aside -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] request for clarification: aside, figure
On Sun, 10 May 2009 08:58:47 +0100, Bruce Lawson bru...@opera.com wrote: Typo in last email: I meant For example, in the middle of a fictional interview about markup, I might want to pull out a quote and citation: Do I write aside blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote citeIan Hickson/cite /aside Or figure blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote legendIan Hickson/legend /figure
[whatwg] Annotating structured data that HTML has no semantics for
One of the more elaborate use cases I collected from the e-mails sent in over the past few months was the following: USE CASE: Annotate structured data that HTML has no semantics for, and which nobody has annotated before, and may never again, for private use or use in a small self-contained community. SCENARIOS: * A group of users want to mark up their iguana collections so that they can write a script that collates all their collections and presents them in a uniform fashion. * A scholar and teacher wants other scholars (and potentially students) to be able to easily extract information about what he teaches to add it to their custom applications. * The list of specifications produced by W3C, for example, and various lists of translations, are produced by scraping source pages and outputting the result. This is brittle. It would be easier if the data was unambiguously obtainable from the source pages. This is a custom set of properties, specific to this community. * Chaals wants to make a list of the people who have translated W3C specifications or other documents, and then use this to search for people who are familiar with a given technology at least at some level, and happen to speak one or more languages of interest. * Chaals wants to have a reputation manager that can determine which of the many emails sent to the WHATWG list might be more than usually valuable, and would like to seed this reputation manager from information gathered from the same source as the scraper that generates the W3C's TR/ page. * A user wants to write a script that finds the price of a book from an Amazon page. * Todd sells an HTML-based content management system, where all documents are processed and edited as HTML, sent from one editor to another, and eventually published and indexed. He would like to build up the editorial metadata used by the system within the HTML documents themselves, so that it is easier to manage and less likely to be lost. * Tim wants to make a knowledge base seeded from statements made in Spanish and English, e.g. from people writing down their thoughts about George W. Bush and George H.W. Bush, and has either convinced the people making the statements that they should use a common language-neutral machine-readable vocabulary to describe their thoughts, or has convinced some other people to come in after them and process the thoughts manually to get them into a computer-readable form. REQUIREMENTS: * Vocabularies can be developed in a manner that won't clash with future more widely-used vocabularies, so that those future vocabularies can later be used in a page making use of private vocabularies without making the earlier annotations ambiguous. * Using the data should not involve learning a plethora of new APIs, formats, or vocabularies (today it is possible, e.g., to get the price of an Amazon product, but it requires learning a new API; similarly it's possible to get information from sites consistently using 'class' values in a documented way, but doing so requires learning a new vocabulary). * Shouldn't require the consumer to write XSLT or server-side code to process the annotated data. * Machine-readable annotations shouldn't be on a separate page than human-readable annotations. * The information should be convertible into a dedicated form (RDF, JSON, XML) 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. * Should be possible for different parts of an item's data to be given in different parts of the page, for example two items described in the same paragraph. (The two lamps are A and B. The first is $20, the second $30. The first is 5W, the second 7W.) * It should be possible to define globally-unique names, but the syntax should be optimised for a set of predefined vocabularies. * Adding this data to a page should be easy. * The syntax for adding this data should encourage the data to remain accurate when the page is changed. * The syntax should be resilient to intentional copy-and-paste authoring: people copying data into the page from a page that already has data should not have to know about any declarations far from the data. * The syntax should be resilient to unintentional copy-and-paste authoring: people copying markup from the page who do not know about these features should not inadvertently mark up their page with inapplicable data. * Any additional markup or data used to allow the machine to understand
Re: [whatwg] Annotating structured data that HTML has no semantics for
On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch wrote: One of the more elaborate use cases I collected from the e-mails sent in over the past few months was the following: USE CASE: Annotate structured data that HTML has no semantics for, and which nobody has annotated before, and may never again, for private use or use in a small self-contained community. [...] To address this use case and its scenarios, I've added to HTML5 a simple syntax (three new attributes) based on RDFa. There's a quickly-hacked-together demo at http://philip.html5.org/demos/microdata/demo.html (works in at least Firefox and Opera), which attempts to show you the JSON serialisation of the embedded data, which might help in examining the proposal. -- Philip Taylor exc...@gmail.com
[whatwg] Custom microdata handling added to HTML5 spec
Since a new section detailing HTML5's handling of custom microdata has been added to the HTML5 spec (tracked here http://html5.org/tools/web-apps-tracker?from=3073to=3074 and displayed here http://dev.w3.org/html5/spec/Overview.html#microdata and announced herehttp://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html ), I'm assuming my effort to re-examine the use cases Ian has published is irrelevant, and a waste of everyone's time. I will hence discontinue any and all effort associated with this specification. Shelley
[whatwg] Continuing
Sorry for the double emails today. I will continue with revisiting the use cases for the microdata section. One additional component I'll add to the use cases is applying my interpretation of how RDFa might handle the use case, as compared to how it could be handled with Ian's new HTML5 microdata proposal. This will, of course, slow me down a bit. Note, though, that I don't claim to be an expert on either RDFa or Ian's new microdata proposal. My hope is that if I make a mistake, or I'm not clear, folks will respond to my writing with corrections and/or additions. The purpose behind my effort is to open discussion. I will admit, though, that I do have a bias for RDFa, primarily because this is something that's real, today, and that I can use, today. Shelley
Re: [whatwg] Annotating structured data that HTML has no semantics for
Quoting Philip Taylor excors+wha...@gmail.com: On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch wrote: One of the more elaborate use cases I collected from the e-mails sent in over the past few months was the following: USE CASE: Annotate structured data that HTML has no semantics for, and which nobody has annotated before, and may never again, for private use or use in a small self-contained community. [...] To address this use case and its scenarios, I've added to HTML5 a simple syntax (three new attributes) based on RDFa. There's a quickly-hacked-together demo at http://philip.html5.org/demos/microdata/demo.html (works in at least Firefox and Opera), which attempts to show you the JSON serialisation of the embedded data, which might help in examining the proposal. I have a *totally unfinished* demo that does something rather similar at [1]. It is highly likely to break and/or give incorrect results**. If you use it for anything important you are insane :) My general impression from writing the tool is that this proposal is, at least, easy to write consumers for. I get the feeling that the production side will also be within the grasp of most authors, although it is hard to say for sure since I haven't really tried authoring anything. [1] http://james.html5.org/microdata/ ** Known bugs include: incorrect lowercasing of non ascii characters, lack of support for resolving uris, lack of rdf output, some others that I forget
Re: [whatwg] Custom microdata handling added to HTML5 spec
Shelley Powers wrote: Since a new section detailing HTML5's handling of custom microdata has been added to the HTML5 spec http://dev.w3.org/html5/spec/Overview.html#microdata I've only had a brief chance to look over the HTML5 Microdata spec, but there is one big problem that overrides all of the other issues: The HTML5 Microdata spec is in direct conflict with planned RDFa extensions and will almost surely result in spurious triples being generated in RDFa processors in the future. We are currently working[1] on features to dynamically extending the base set of reserved words and the set of pre-defined prefixes through a mechanism called RDFa Profiles[2]. It is proposed that this mechanism would allow authors to do this in their documents: div profile=http://example.org/myprofile.html; ... span property=descriptionA description for this page./span span about=#me property=nameManu Sporny/span /div Note that 'description' and 'name' are not prefixed, but would be mapped to a full URI in the document listed by @profile. This allows the ease of Microformats-like markup but with all of the rigor of RDFa. The HTML5 microdata proposal, as it stands right now, would create numerous spurious triples if implemented and would violate the purpose of @property as it is being developed in the RDFa community. I'll have more comments on the microdata proposal based on the response to this e-mail. -- manu [1]http://www.w3.org/2009/04/30-rdfa-minutes.html#item04 [2]http://rdfa.info/wiki/RDFa_Profiles -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: A Collaborative Distribution Model for Music http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/
Re: [whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
Julian wrote: You are aware of MNot's Web Linking draft (http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html), and the fact that it seems to enjoy support from the TAG? Julian, you continue to bring this up as if we hadn't already discussed this: there are significant differences of opinion with mnot on whether his interpretation of @rel values is correct in prior HTML versions, and there are a number of folks who disagree (not just us in RDFa), including at least two RECs (RDFa and GRDDL). The point is: if you assume that @rel=foo always means the same thing, then many folks believe you're already violating the HTML spec, which specifically uses @profile to modulate the meaning of @rel, and sometimes via another level of indirection. -Ben
Re: [whatwg] Helping people seaching for content filtered by license
Ben Adida ben at adida.net Sun May 10 15:29:53 PDT 2009: Julian wrote: You are aware of MNot's Web Linking draft (http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html), and the fact that it seems to enjoy support from the TAG? Julian, you continue to bring this up as if we hadn't already discussed this: Where and when has it been discussed? there are significant differences of opinion with mnot on whether his interpretation of @rel values is correct in prior HTML versions, He has Requested For Comments, so that can be corrected, no? and there are a number of folks who disagree (not just us in RDFa), including at least two RECs (RDFa and GRDDL). Is this claim based on a mere comparison of the description of those link relations in said specifications? Perhaps some of the disagreements are merely a different wording? The point is: if you assume that @rel=foo always means the same thing, then many folks believe you're already violating the HTML spec, which specifically uses @profile to modulate the meaning of @rel, and sometimes via another level of indirection. Where does nottingham draft define anything that contradicts the default HTML 401 profile? Authors will often assume that rel=foo does means the same thing wherever it appears, hence a central register is a benefit so that specification writers and profile writers can know what the standard semantics are. As to modifying semantics, it is probably not wise to profile or specify semantics that differs from the central register. But having a central register cannot in itself prevent profiles (default profiles or linked-in profiles) from defining their own semantics when necessary. It does by the way seem like an unfortunate mix of semantics and other issues that HTML 5 does not allow the @rev attribute. Rather, HTML 5 should allow the @rev attribute, but should eventually say that it hasn't defined any values for it. Thus authors who are linking to a profile that does define values for @rev could still use @rev without producing an invalid HTML 5 document. -- leif halvard silli
[whatwg] Asynchronous file upload
I was asked by a client if it was possible to implement something similar to the asynchronous file upload used on gmail using only standard web technologies. Looking at the gmail source code I can see that they use some flash magic. And by reading the HTML5 spec I could not find a way to implement this feature. Wouldn't it be great if this was possible? -- Samuel Santos http://www.samaxes.com/
Re: [whatwg] Asynchronous file upload
W liście Samuel Santos z dnia poniedziałek 11 maja 2009: I was asked by a client if it was possible to implement something similar to the asynchronous file upload used on gmail using only standard web technologies. Looking at the gmail source code I can see that they use some flash magic. And by reading the HTML5 spec I could not find a way to implement this feature. Submitting the form that contains file upload to a iframe. The question does not seem to belong to this list, does it? -- Paweł Stradomski
Re: [whatwg] Asynchronous file upload
There appears to be some W3C activity regarding this problem. There is a draft about file uploads[1] which is edited by a Mozilla employee. This is not accidentally. As of Firefox 3 we have the possibility of Ajax file uploads. The API resembles pretty much the draft. Also, Safari 4 and Chrome 2 - WebKit in other words - provide an API for the same purpose, but it has less to do with the above mentioned standard draft. I've written an extensive post [2] about the API in Firefox 3. Maybe it will help you. [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html [2] http://igstan.blogspot.com/2009/01/pure-javascript-file-upload.html On 5/11/2009 02:51, Samuel Santos wrote: I was asked by a client if it was possible to implement something similar to the asynchronous file upload used on gmail using only standard web technologies. Looking at the gmail source code I can see that they use some flash magic. And by reading the HTML5 spec I could not find a way to implement this feature. Wouldn't it be great if this was possible? -- Samuel Santos http://www.samaxes.com/ -- Ionut G. Stan I'm under construction | http://igstan.blogspot.com/
Re: [whatwg] video/audio feedback
At 14:09 +1000 9/05/09, Silvia Pfeiffer wrote: you might try loading, say, the one-page version of the HTML5 spec. from the WhatWG site...it takes quite a while. Happily Ian also provides a multi-page, but this is not always the case. That just confirms the problem and it's obviously worse with video. :-) The reason I want clarity is that this has ramifications. For example, if a UA is asked to play a video with a fragment indication #time=10s-20s, and then a script seeks to 5s, does the user see the video at the 5s point of the total resource, or 15s? I think it has to be 5s. I agree, it has to be 5s. The discussion was about what timeline is displayed and what can the user easily access through seeking through the displayed timeline. A script can access any time of course. But a user is restricted by what the user interface offers. Sure. I think we are probably in agreement. Logically, the UA is dealing with the whole resource -- which is why it's 5s in this case. The UA is also responsible for focusing the user on the fragment, and (implicitly) for optimizing the network for what the user is focusing on. For example, some UAs would essentially invoke the same code if the user immediately did a seek to a time, if the javacsript did a seek to a time, or the initial URI had a fragment indicator starting at a time. In all three cases, the UA tries to start at that time as best it can, optimizing network access to do that. But we can optimize for the fragment without disallowing the seeking. What do you mean by optimize for the fragment? I mean, the UA can get support from the server for time-based access, helping optimizing the network access for the fragment to be presented, while at the same time allowing seeking outside that fragment. Of course none of the discussion will inherently disallow seeking - scripts will always be able to do the seeking. But the user may not find it easy to do seeking to a section that is not accessible through the displayed timeline, which can be both a good and a bad thing. How easy a particular user interface is to use for various tasks is (I hope) not our worry... -- David Singer Multimedia Standards, Apple Inc.
