Re: [whatwg] A new attribute for video and low-power devices
On 18/5/09 22:28, Benjamin M. Schwartz wrote: Then I will attempt to convince you. Suppose the additional attribute is a boolean called decorative, defaulting to false if not present. Note that /if/ ARIA roles are ultimately incorporated in text/html, that would more or less duplicate role=presentation. http://www.w3.org/TR/wai-aria/#presentation -- Benjamin Hawkes-Lewis
Re: [whatwg] A new attribute for video and low-power devices
On Tue, 19 May 2009 07:03:14 +0100, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On 18/5/09 22:28, Benjamin M. Schwartz wrote: Then I will attempt to convince you. Suppose the additional attribute is a boolean called decorative, defaulting to false if not present. Note that /if/ ARIA roles are ultimately incorporated in text/html, that would more or less duplicate role=presentation. http://www.w3.org/TR/wai-aria/#presentation Good spot, Benjamin. Hixie said in an interview I did with him ..The plan is to make sure ARIA and HTML5 work well together. Right now I’m waiting for ARIA to be complete (there are a number of last call comments that they haven’t yet replied to), and for the ARIA implementation rules to be clearer (it’s not yet obvious as I understand it what should happen when ARIA says a checkbox is a radio button, for instance). Once that is cleared up, I expect HTML 5 will give a list of conformance criteria saying where ARIA attributes can be used and saying how they should be implemented in browsers. http://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/ So perhaps this is a leverageable synergy?
Re: [whatwg] Reserving id attribute values?
On Tue, 19 May 2009 03:20:49 +0200, Brett Zamir bret...@yahoo.com wrote: In order to comply with XML ID requirements in XML, and facilitate future transitions to XML, can HTML 5 explicitly encourage id attribute values to follow this pattern (e.g., disallowing numbers for the starting character)? Those are only validity requirements and only when DTDs are involved (and possibly XSD) so it doesn't really matter. Also, there is this minor errata: http://www.whatwg.org/specs/web-apps/current-work/#refsCSS21 is broken (in section 3.2) References in general are not done yet. (Will be fixed in August or so per the issue tracker.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Reserving id attribute values?
Anne van Kesteren wrote: On Tue, 19 May 2009 03:20:49 +0200, Brett Zamir bret...@yahoo.com wrote: In order to comply with XML ID requirements in XML, and facilitate future transitions to XML, can HTML 5 explicitly encourage id attribute values to follow this pattern (e.g., disallowing numbers for the starting character)? Those are only validity requirements and only when DTDs are involved (and possibly XSD) so it doesn't really matter. While it may not be that common, people may want at a later date to apply some files for validation... And don't forget the vanity/business factor in having a fully validating site :) Brett
Re: [whatwg] Reserving id attribute values?
On Tue, 19 May 2009 13:46:43 +0200, Brett Zamir bret...@yahoo.com wrote: While it may not be that common, people may want at a later date to apply some files for validation... And don't forget the vanity/business factor in having a fully validating site :) You can have validation outside the DTD/XSD realm. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Reserving id attribute values?
Anne van Kesteren wrote: On Tue, 19 May 2009 13:46:43 +0200, Brett Zamir bret...@yahoo.com wrote: While it may not be that common, people may want at a later date to apply some files for validation... And don't forget the vanity/business factor in having a fully validating site :) You can have validation outside the DTD/XSD realm. Sorry I guess I was forgetting that HTML can be validated just as well. However, whichever way one validates, RelaxNG or whatever, XHTML 5 (and HTML 5?) will still define it as an ID type, no? This concern was brought to mind when looking at http://dev.w3.org/html5/html4-differences/#absent-attributes which simply suggests using id instead of name (some might just think they can simply switch the attribute and not the value). Brett
Re: [whatwg] Reserving id attribute values?
On Tue, 19 May 2009 14:14:06 +0200, Brett Zamir bret...@yahoo.com wrote: Sorry I guess I was forgetting that HTML can be validated just as well. However, whichever way one validates, RelaxNG or whatever, XHTML 5 (and HTML 5?) will still define it as an ID type, no? Even when defined as of type ID you can still validate it when it starts with a digit, in XML. Just not with DTD/XSD validation. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Reserving id attribute values?
On May 19, 2009, at 15:14, Brett Zamir wrote: However, whichever way one validates, RelaxNG or whatever, XHTML 5 (and HTML 5?) will still define it as an ID type, no? The RELAX NG DTD Compatibility feature isn't all that useful in practice, so no, you probably wouldn't make it have IDness on the RELAX NG level. (Validator.nu doesn't.) Even if you do, you can mint a custom RELAX NG datatype that has IDness but doesn't have the lexical constraints of DTD ID or XSD ID. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] SVG extensions to canvas
On Wed, 06 May 2009 22:16:50 +0200, Oliver Hunt oli...@apple.com wrote: That svg hasn't got intrinsic sizes, so it cannot be rendered on a canvas. This doesn't preclude the use of svg with intrinsic sizes, that are given only by width/height attributes on svg. That's really really bad, as that means sometimes drawing you svg will work, and sometimes it won't. That's why it's a bad API. That's not quite what we implemented (and proposed) though. In case there is no intrinsic size you'd just fall back to a default size. I.e. similar to how img, iframe, etc. work. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Exposing known data types in a reusable way
Some of the use cases I collected from the e-mails sent in over the past few months were the following: USE CASE: Exposing contact details so that users can add people to their address books or social networking sites. SCENARIOS: * Instead of giving a colleague a business card, someone gives their colleague a URL, and that colleague's user agent extracts basic profile information such as the person's name along with references to other people that person knows and adds the information into an address book. * A scholar and teacher wants other scholars (and potentially students) to be able to easily extract information about who he is to add it to their contact databases. * Fred copies the names of one of his Facebook friends and pastes it into his OS address book; the contact information is imported automatically. * Fred copies the names of one of his Facebook friends and pastes it into his Webmail's address book feature; the contact information is imported automatically. * David can use the data in a web page to generate a custom browser UI for including a person in our address book without using brittle screen-scraping. REQUIREMENTS: * A user joining a new social network should be able to identify himself to the new social network in way that enables the new social network to bootstrap his account from existing published data (e.g. from another social nework) rather than having to re-enter it, without the new site having to coordinate (or know about) the pre-existing site, without the user having to give either sites credentials to the other, and without the new site finding out about relationships that the user has intentionally kept secret. (http://w2spconf.com/2008/papers/s3p2.pdf) * Data should not need to be duplicated between machine-readable and human-readable forms (i.e. the human-readable form should be machine-readable). * Shouldn't require the consumer to write XSLT or server-side code to read the contact information. * Machine-readable contact information shouldn't be on a separate page than human-readable contact information. * The information should be convertible into a dedicated form (RDF, JSON, XML, vCard) 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 a contact to be given in different parts of the page. For example, a page with contact details for people in columns (with each row giving the name, telephone number, etc) should still have unambiguous grouped contact details parseable from it. * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. USE CASE: Exposing calendar events so that users can add those events to their calendaring systems. SCENARIOS: * A user visits the Avenue Q site and wants to make a note of when tickets go on sale for the tour's stop in his home town. The site says October 3rd, so the user clicks this and selects add to calendar, which causes an entry to be added to his calendar. * A student is making a timeline of important events in Apple's history. As he reads Wikipedia entries on the topic, he clicks on dates and selects add to timeline, which causes an entry to be added to his timeline. * TV guide listings - browsers should be able to expose to the user's tools (e.g. calendar, DVR, TV tuner) the times that a TV show is on. * Paul sometimes gives talks on various topics, and announces them on his blog. He would like to mark up these announcements with proper scheduling information, so that his readers' software can automatically obtain the scheduling information and add it to their calendar. Importantly, some of the rendered data might be more informal than the machine-readable data required to produce a calendar event. * David can use the data in a web page to generate a custom browser UI for adding an event to our calendaring software without using brittle screen-scraping. * http://livebrum.co.uk/: the author would like people to be able to grab events and event listings from his site and put them on their site with as much information as possible retained. The fantasy would be that I could provide code that could be cut and pasted into someone else's HTML so the average blogger could re-use and re-share my data. * User should be able to subscribe to http://livebrum.co.uk/ then sort by date and see the items sorted by event date, not publication date. REQUIREMENTS: * Should be
[whatwg] Dragging or copying data between sites
Two of the use cases I collected from the e-mails sent in over the past few months were the following: USE CASE: Copy-and-paste should work between Web apps and native apps and between Web apps and other Web apps. SCENARIOS: * Fred copies an e-mail from Apple Mail into GMail, and the e-mail survives intact, including headers, attachments, and multipart/related parts. * Fred copies an e-mail from GMail into Hotmail, and the e-mail survives intact, including headers, attachments, and multipart/related parts. USE CASE: Allow users to share data between sites (e.g. between an online store and a price comparison site). SCENARIOS: * Lucy is looking for a new apartment and some items with which to furnish it. She browses various web pages, including apartment listings, furniture stores, kitchen appliances, etc. Every time she finds an item she likes, she points to it and transfers its details to her apartment-hunting page, where her picks can be organized, sorted, and categorized. * Lucy uses a website called TheBigMove.com to organize all aspects of her move, including items that she is tracking for the move. She goes to her To Do list and adds some of the items she collected during her visits to various Web sites, so that TheBigMove.com can handle the purchasing and delivery for her. REQUIREMENTS: * Should be discoverable, because otherwise users will not use it, and thus users won't be helped. * Should be consistently available, because if it only works on some pages, users will not use it (see, for instance, the rel=next story). * Should be bootstrapable (rel=next failed because UAs didn't expose it because authors didn't use it because UAs didn't expose it). * 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. * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. I addressed both of these by allowing authors to mark up data using the microdata feature described in previous e-mails, defining an unambiguous conversion to JSON for all microdata, and then requiring all drag-and-drop operations to include this JSON data for the selection. However, support for dragging things from native applications or from Web pages _to_ a Web page will require support from the Web page itself. * Fred copies an e-mail from Apple Mail into GMail, and the e-mail survives intact, including headers, attachments, and multipart/related parts. This can actually be done today (per spec). GMail would have to support the format that Apple Mail puts on the clipboard, however. * Fred copies an e-mail from GMail into Hotmail, and the e-mail survives intact, including headers, attachments, and multipart/related parts. Assuming that GMail and Hotmail support the same formats, this could also be done today using the drag-and-drop APIs (though getting attachments would probably not work easily, since those are probably server-side -- maybe whoever comes up with a format for this will define a way to expose the attachments at obfuscated URLs, instead of requiring the client to transfer the data between the sites itself). * Lucy is looking for a new apartment and some items with which to furnish it. She browses various web pages, including apartment listings, furniture stores, kitchen appliances, etc. Every time she finds an item she likes, she points to it and transfers its details to her apartment-hunting page, where her picks can be organized, sorted, and categorized. Assuming her apartment-hunting page and the various web pages, including apartment listings, furniture stores, kitchen appliances, etc, all support the same set of vocabularies, this is now possible. (This's quite an assumption, but I don't see any other way to do it.) * Lucy uses a website called TheBigMove.com to organize all aspects of her move, including items that she is tracking for the move. She goes to her To Do list and adds some of the items she collected during her visits to various Web sites, so that TheBigMove.com can handle the purchasing and delivery for her. This will need some work from people to define vocabularies for products and purchasing details, etc, but assuming that exists, this should be possible using the infrastructure now provided with the drag-and-drop API and microdata. * Should be discoverable, because otherwise users will not use it, and thus users won't be helped. Presumably, sites would advertise this functionality, e.g. by having icons that represent draggable content in
[whatwg] Cross-domain databases; was: File package protocol and manifest support?
I would like to suggest an incremental though I believe significant enhancement to Offline applications/SQLite. That is, the ability to share a complete database among offline applications according to the URL from which it was made available. It could be designated by the origin site as a read-only database, or also potentially with shared write access, shareable with specific domains or all domains, and perhaps also with a mechanism to indicate the license of its contents. Perhaps the manifest file could include such information. Actually, there might even be a shared space for databases directly downloaded by the user (or by an application) which would allow all applications access, no doubt requiring UA permission. Ideally the origin site could also have control over providing an update to the database (not necessarily through manually performing UPDATE commands, but potentially by simply providing a new database at the previous location which was checked periodically for a new modification date). I don't know whether it would ideal to tie this in to the caching API (perhaps deleting the database reference could also cause it to be re-downloaded and also force the database to be re-created). Perhaps the cache API could also be optionally shared with other domains as well, allowing them to ensure their application was working with the latest data. I believe custom protocols will also play into this well, as there could be a number of uses for operating on the same data set while linking to it in a way which is application-independent. (Thanks to Kristof Zelechovski for helping me distill the essence of the idea a bit more succinctly and more in line with HTML 5's progress to date.) Brett
[whatwg] HTML5 ruby spec: rp
As I am currently in the process of writing an implementation for ruby, I
was wondering about the constraints put on the content of the rp element
in the spec:
If the rp http://dev.w3.org/html5/spec/Overview.html#the-rp-elementelement
is immediately after an
rt http://dev.w3.org/html5/spec/Overview.html#the-rt-element element that
is immediately preceded by another
rphttp://dev.w3.org/html5/spec/Overview.html#the-rp-elementelement:
a single character from Unicode character class Pe. Otherwise:
a single character from Unicode character class Ps.Is there a specific
reason that rp is constrained in this way? I imagine that someone could
want to add additional spaces before/after the parenthesis, non-parenthesis
separators, or, e.g., in a text book write:
*ruby*漢字*rp *(reading:*/rprt*Kanji*/rt**rp*) */rpruby
*
Also note that there isn't such a constraint if one would use CSS rules to
achieve a similar result (in the absence of proper ruby rendering):
rt:before { content: (reading: ; }
rt:after { content: ) ; }
Cheers,
- Roland
Re: [whatwg] File package protocol and manifest support?
On Mon, May 18, 2009 at 5:41 AM, Brett Zamir bret...@yahoo.com wrote: While this may be too far in the game to bring up, I'd very much be interested (and think others would be too) to have a standard means of representing not only individual files, but also groups of files on the web. One application of this would be for a web user to be able to do the following (taking advantage of both offline applications and related somewhat to custom protocols): 1) Click a link in a particular protocol containing a list of files or leading to a manifest file which contains a list of files. Very importantly, the files would NOT need to be from the same site. 2) If the files have not been downloaded already, the browser accesses the files (possibly first decompressing them) to store for offline use. 3) If the files were XML/XHTML, take advantage of any attached XSL, XQuery, or CSS in reassembling them. 4) If the files were SQL, reassemble them in a table-agnostic manner--e.g., allow the user to choose which columns to view and in which order and how many records at a time (including allowing a single-record flashcard-like view), also allowing for automated generation of certain columns using JavaScript. 5) If the files included templates, use these for the display and populate for the user to view. 6) Bring the user to a particular view of the pages, starting for example, at a particular paragraph indicated by the link or manifest file, highlight the document or a portion of the targeted page with a certain font and color, etc. It seems limiting that while we can reference individual sites' data at best targeting an existing anchor or predefined customizability, we do not have any built-in way to bookmark and share views of that data over the web. In considering building a Firefox extension to try this as a proof of concept, METS (http://www.loc.gov/standards/mets/ ) seems to have many aspects which could be useful as a base in such a standard, including the useful potential of enabling links to be described for files which may not exist as hyperlinks within the files--i.e., XLink linkbases). Besides this offline packages use, such a language might work just as well to build a standard for hierarchical sitemaps, linkbases, or Gopher 2.0 (and not being limited to its usual web view, equivalent of icon view on the desktop, but conceivably allowing column browser or tree views for hierarchical data ranging from interlinked genealogies to directories along the lines of http://www.dmoz.org/ or http://dir.yahoo.com ), including for representing files on one's own local system yet leading to other sites. The same manifest files might be browseable directly (e.g., Gopher-mode), being targeted to continguously lead to other such manifest file views until reaching a document (the Gopher-view could optionally remain in sight as the end document loaded), or, as mentioned above, as a cached and integrated offline application (especially where compressed files and SQL were involved). Developing a Firefox extension is a sure way to strengthen your case. It will help expose the real requirements, and highlight weaknesses in the proposal. Actual users will show you what parts are popular and which aren't, which can direct one's efforts in adding things to the spec. ~TJ
Re: [whatwg] Link rot is not dangerous
On Mon, May 18, 2009 at 7:26 AM, Henri Sivonen hsivo...@iki.fi wrote: On May 18, 2009, at 14:45, Dan Brickley wrote: Since there is useful information to know about FOAF properties and terms from its schema and human-oriented docs, it would be a shame if people ignored that. Since domain names can be lost, it would also be a shame if directly de-referencing URIs to the schema was the only way people could find that info. Fortunately, neither is the case. I wasn't talking about people but about apps dereferencing NS URIs to enable their functionality. Specifically, people can use a search engine to find information about foaf. I know that typing foaf into my browser's address bar and clicking on the first likely link is *way* faster than digging into a document with a foaf namespace declared, finding the url, and copy/pasting that into the location bar. There are always decent search terms around to help people find the information at least as easily, and certainly more reliably, than an embedded url. The just use a search engine position has been brought up by Ian with respect to multiple cases in the overall discussion as well. For humans, search engines are just more reliable and easier to use than a uri (at least, a uri in a non-clickable context). ~TJ
