Re: [whatwg] Technical Parity with W3C HTML Spec
How is that productive? I realize that it's meant as a joke but it does nothing but add to the impression that some in the WHATWG community just don't care about civility, respect, and cooperation. The best thing to counteract that impression is to prove it wrong. On Jun 25, 2010, at 8:51 AM, Perry Smith wrote: On Jun 25, 2010, at 5:13 AM, Doug Schepers wrote: There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. 5) W3C could go away
Re: [whatwg] input type=upload (not just files) proposal
Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: It would then be the server's job to fetch the file unless the user passed it a file:// scheme it which case the file would be provided by the UI.
Re: [whatwg] input type=upload (not just files) proposal
O.K. Just wanted to clarify. With this sort of dialog in mind, I like your proposal. (I find it unrealistic to think that the average user would write out file://... but maybe I am mistaken.) However, I see one possible issue. Some apps provide the means to work with local files, URLs, and direct text input (such as the W3C's validator: http://validator.w3.org/). Might others expand your suggestion to include the direct text option? I don't have an opinion on that other than to say that the appropriate balance between utility and complexity would need to be found. On Jun 8, 2010, at 10:45 AM, Eitan Adler wrote: On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton glsim...@indiana.edu wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: It would then be the server's job to fetch the file unless the user passed it a file:// scheme it which case the file would be provided by the UI. I imagine this would be a UI decision - not one made by the spec. However I, with very limited experience in UI creation, am envisioning a dialog box as you mention. Another option would be to have buttons to the side of the textbox one that has a web icon and another that has a folder icon. -- Eitan Adler
Re: [whatwg] 'Main Part of the Content' Idiom
For the record, I don't disagree with any of what you said below. On Jun 7, 2010, at 5:13 AM, Daniel Persson wrote: But wouldn't we create a situation where the main content tag is misused and essentially then we'd recreate the situation with body? IMHO you can't stop tags from being misused, and that goes for any tag. What I am taking about is that it is upside down to expect honest people to define everything except the main content. Pedagogically and methodologically. Main content is main content, the most important to define. That should be the starting point for the structure. Not all html-developing pros have a consciousness when it comes to writing correct mark-up and the non-pros just want to publish their content. One of the points of html5 is to make it easier to do the right thing mark-up-wise, to be structured and in standards compliance. The simplest tutorial on html5 authoring should be: Getting doctype and charset right, html, head, body. Then define main content. Finished. Ready to be indexed. For the following tutorials, mark up the rest of the structure (if you can be bothered/have the time/stamina/lust) learning all of the structural tags. Then add all the bits and bobs that are not necessarily part of any definable structure, finding some suitable tag for that gallery of lolcats that is popping up when you hover a link. Many people interested in just publishing their content will have dropped off by now, not really paying attention to the correct tags as long as it works on the screen... ...bu at least the main content (as defined by the author) can be reached, indexed, sorted or stacked by machines. All the best /Daniel
Re: [whatwg] 'Main Part of the Content' Idiom
But wouldn't we create a situation where the main content tag is misused and essentially then we'd recreate the situation with body? Best, Grant On Jun 4, 2010, at 12:39 PM, Daniel Persson wrote: I am not advocating ad-tags. The idea of globally structuring content on the web is very appealing, it would make it easier for a lot of things and a lot of people. Let's do it! ...but I can't see it happening where body would be main content + ads + anything there is not a sensible tag for + anything a lazy/stressed/unconscious author didn't tag otherwise. Let's just have a main content tag or a strong main content strategy. Thanks /Daniel On Fri, Jun 4, 2010 at 6:07 PM, Ashley Sheridan a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 18:03 +0200, Daniel Persson wrote: Some websites are very crowded. I have no particular example. Blogs and easily accessible CMS's, people trying to make a buck from excessive advertising on their site, people cramming a lot of info/screen unit. Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper, watch your eyes) . body will hold a lot of stuff that is not main content, other content will spill over into body (unless there is a conscious author, and vast use of aside). It should be easy for authors to define main content. It s a pedagogical issue, where authors not too concerned with standards compliance, should have an easy escape of at least defining the most important on the site. Thanks /Daniel On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote: If i view the html-web as it is now, inside body there are so much irrelevant content (where else to put it?). In order for body to be the main content, there has to be tags for everything else. This will be very hard for authors to implement (I am talking real world, amateur, do-it-yourself, stressed professionals). It is IMHO very beautiful code-wise, and organisationally, to state that everything in body is main content, but it will not benefit a structurally marked-up web. Thanks /Daniel On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote: I am the one posting the question on the help list. To me, the lack of html5 definition of main content, ie body copy in paper publishing, is a big mistake. Imagine the amount of sites where everything else includes a lot of unimportant extra, or peripheral, content. Content which is not necessarily hierarchically legible by a machine. Getting authors to be disciplined about defining main content is more important than being disciplined about nav, footer, header, section etc, in order not to negate the meaning of html5 structural mark-up. Suggestion bodycopy... or, preferred, bread. /Daniel On Fri, Jun 4, 2010 at 1:55 PM, Smylers smyl...@stripey.commailto:smyl...@stripey.com wrote: The HTML5 spec should define how to mark up the main content on a page (even if the answer is by omission). This is something that many authors ask about, the latest example being today's thread on the help mailing list: http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html Please could this be added to the 'idioms' section, perhaps giving examples of when article or section might be appropriate as well as one in which the main content is simply that which isn't in header, aside, etc. Thanks. Smylers -- http://twitter.com/Smylers2 It's my understanding that everything within the body tag is considered body content, and the new header and footer tags, etc, are just there to give more meaning about the type of body content. Thanks, Ash http://www.ashleysheridan.co.ukhttp://www.ashleysheridan.co.uk/ The fact that there is so much irrelevant content inside the body tag is because some people consider that body content. Do you have a more specific example of this? Thanks, Ash http://www.ashleysheridan.co.ukhttp://www.ashleysheridan.co.uk/ I believe there was a proposal for an advert tag purely for adverts (I don't remember where I heard it) but it wasn't a realistic idea. If we could easily identify content we didn't want to see, and could strip it out before it even got to our browser, what incentive would people have to use it if the adverts are their only source of revenue? As such, it's not very feasible to distinguish between different types of content, and even if there were tags, a lot of people wouldn't use them because it would have a negative impact. Thanks, Ash http://www.ashleysheridan.co.ukhttp://www.ashleysheridan.co.uk/
Re: [whatwg] Installable web apps
One question I have off the top of my head is how updates are handled. I like the idea of better integration with the OS and the browser but I don't want to lose one of what I see as the best elements of web app development, namely the need to not have to update clients' copies of the app individually. On May 24, 2010, at 4:45 PM, Aaron Boodman wrote: This has come up before, but since Google has officially announced the project at IO, and Mozilla has voiced interest in the idea on their blog, I felt like it might be a good to revisit. Google would like to make today's web apps installable in Chrome. From a user's point of view, installing a web app would: - Give it a permanent access point in the browser with a big juicy icon - Allow the browser to treat a web app as a conceptual unit (eg give it special presentation, show how much storage it uses) - Add some light integration with the OS - (optionally) Pre-grant some permissions that would otherwise have to be requested one-at-a-time (eg geolocation, notifications) - (optionally) Grant access to some APIs that would otherwise be inaccessible (eg system clipboard, permanent storage) There is some more background on our thinking at these two URL: http://code.google.com/chrome/apps/ http://code.google.com/chrome/apps/docs We have started implementing this using Chrome's current extension system. However, we'd like it if installation could eventually work in other browsers. Is there any interest from other vendors in collaborating on the design of such a system? Thanks, - a
Re: [whatwg] Installable web apps
This is what I had assumed. I love the idea. However, I think installation is a bad metaphor, given that users will have preconceived notions about what installation means, namely that installed apps live on their machine and are under their control (for the most part). On May 25, 2010, at 10:33 AM, Anne van Kesteren wrote: On Tue, 25 May 2010 16:12:44 +0200, Simpson, Grant Leyton glsim...@indiana.edu wrote: One question I have off the top of my head is how updates are handled. I like the idea of better integration with the OS and the browser but I don't want to lose one of what I see as the best elements of web app development, namely the need to not have to update clients' copies of the app individually. Presumably the installed app would still be delivered over HTTP; potentially with a lot of offline data through storage and a cache manifest. installed seems to be just a bit on top of what we have already that gives a few extra features. At least that's what I make out of the rough summary. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Expanding the cite element
I was unaware of the Microdata spec. Now that I have seen it, I think it offers a lot of power and flexibility. I think it should adequately cover the use case I was thinking of. I'm in favor of adding a non-normative note to the section of the HTML5 spec that discusses cite that demonstrates how Microdata or RDFa could be used for this purpose. There will likely be other people like me who read the cite section of the spec and think What? I can't actually make the citation point to something? On May 8, 2010, at 8:41 AM, Benjamin Hawkes-Lewis wrote: I'm not opposed to adding @cite to cite but note that when you are identifying a resource rather than linking to a resource, you could use microdata or RDFa. For example: http://dev.w3.org/html5/md/#global-identifiers-for-items http://rdfa.info/wiki/Rdfa-microdata-markup-comparison#Book_markup_with_ISBN_and_description
Re: [whatwg] Expanding the cite element
On May 6, 2010, at 11:14 AM, Edward O'Connor wrote: Consider how the above would work in legacy browsers, and then consider how this would work in them: pAs Ashley Crandall Amos says in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/a/cite ... Amos also mentions in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means/a/cite/p Ted, I'm almost satisfied with your approach except for three things: 1. Referencing something in the href attributed of an a tag implies that the URI will resolve to a URL, that is, that it will be accessible on the web at that address. Not every URI is a URL, though. That's what I was trying to do with a uri attribute for the cite tag is to identify the resource, not necessarily link to it. 2. We would have to formally define what a within cite means, otherwise we would leave the pairing up for interpretation. 3. Are there instances where tags that can be used separately take on a different meaning in relation to one another? I know what li means in relation to ol and ul, but then again, I can't really use li outside of either of those two. Best, Grant
[whatwg] Expanding the cite element
Dear WHATWG list participants, Forgive me if this conversation has been had before; I've just recently joined the list. Is there any value in adding an href or uri or similar attribute to the cite element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically? q has a cite attribute, so it seems to me that if we have a place to link to further information in q it makes sense to do so in cite. After all, whether an author quotes from a reference (q) or merely discusses it without quoting (cite), both of these would end up in a works cited in a traditional paper. Therefore, I think both should link (or refer) to somewhere. If it were a URI (and therefore not necessarily retrievable), it would help in cases where the same work gets referenced in slightly different ways: pAs Ashley Crandall Amos says in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/cite ... Amos also mentions in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means/cite/p ✍ Best, Grant Simpson ¶ Senior Analyst/Programmer, Office of the Registrar ¶ Doctoral Student, Department of English ¶ Representative, IU Bloomington Professional Council Indiana University Bloomington
