[whatwg] Sort child nodes of a DOM node.
There are many cases where we want to sort child nodes of a DOM node.
Many times it is TR nodes of a TBODY
Right now user writes javascript code to achive that.
Dont you think it is better if there was built DOM method for each node.
Additionally the method will have a sort function parameter to compare elements
the same way as in JavaScript Array.sort(compare_func)
function compare_func(a,b){
if(isHeaderRow(a)) return -1;
if(isHeaderRow(b)) return 1;
if(a.textContent == b.textContent) return 0;
if(a.textContent b.textContent) return -1;
return 1;
}
tablebody.sortChildNodes(compare_func)
Use cases:-
Example 1: column sorting in yahoo mail
Example 2: you can sort this listing by clicking the column headers
https://bugzilla.mozilla.org/buglist.cgi?short_desc=sortshort_desc_type=allwordssubstrresolution=---
Example 2: there are bug report in mozilla asking sorting in XUL grids
https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890hide_resolved=1
Re: [whatwg] fixBrokenLink is not defined
Garrett Smith dhtmlkitc...@gmail.com, 2010-06-03 16:08 -0700: On 6/3/10, Ian Hickson i...@hixie.ch wrote: On Thu, 3 Jun 2010, Garrett Smith wrote: I have noticed over the last year or so, the error fixBrokenLink often popping up. fixBrokenLink is not defined. I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla I think it's this: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9650 http://dev.w3.org/html5/spec/Overview.html fixBrokenLink is not defined. Does this error occur with the WHATWG versions of the spec? If not, then please report it to the W3C, not the WHATWG (it's probably an issue with Mike's spec splitter script). \ I'm not gonna check because that size freezes the browser. There's also a multipage WHATWG version - http://www.whatwg.org/specs/web-apps/current-work/multipage/ -- Michael(tm) Smith http://people.w3.org/mike
Re: [whatwg] WebSockets: UDP
Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work? They seem both seem to be session oriented while loosening the other restrictions of TCP, On 4 June 2010 00:18, Philip Taylor excors+wha...@gmail.comexcors%2bwha...@gmail.com wrote: On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller emol...@opera.com wrote: [...] One thing to remember here is that browsers have other means for communication as well. I'm not saying we shouldn't support reliable messages over UDP, but just pointing out the option. Yep - the relevant use cases ought to be supported decently by the platform, but not necessarily by this extension to the platform (it might be a different extension or it might be (probably is) supported already). - Protection against an attacker initiating a legitimate socket with a user and then redirecting it (with some kind of IP (un)hijacking) to a service behind the user's firewall (which isn't a problem when using TCP since the service will ignore packets when it hasn't done the TCP handshake; but UDP services might respond to a single packet from the middle of a websocket stream, so every single packet will have to be careful not to be misinterpreted dangerously by unsuspecting services). I don't quite follow what you mean here. Can you expand on this with an example? I was thinking something like: A host at IP 11.11.11.11 on the public internet runs some UDP service, like DNS or TFTP or something a bit more secure. That service is restricted so it only responds to packets received from IP 22.22.22.22 (a trusted user). The UDP Web Socket handshake is carefully constructed so that it won't trigger dangerous behaviour in any of those services (like how the TCP Web Socket uses a safe HTTP-ish handshake). An attacker hijacks the IP 11.11.11.11 from the perspective of the user (by advertising new routes near the user), so the user's packets to that address go to the attacker. The attacker gets the user to visit a web page which sets up a UDP Web Socket with the attacker's server at 11.11.11.11, doing all the handshake authentication correctly. The attacker then releases its hijacked address, so any subsequent Web Socket packets will go to the original restricted service. Since they're being received from the trusted user, the service will trust them. Since the web browser has already done the Socket handshake, it will believe it's talking to a legitimate Web Socket server and will continue sending whatever data packets the attacker's script tells it to. The service will then be receiving and responding to attacker-controlled packets, and will never have seen the carefully constructed handshake that's designed to protect it. That's not a danger for TCP services since they'll reject unexpected packets from the middle of a TCP stream, but UDP services may accept packets from the middle of a UDP Web Socket stream. So it's not sufficient to carefully construct the Web Socket handshake packets to not trigger unwanted behaviour in non-Socket services. Every data packet sent on the Socket has to be carefully constructed too. (This might be a largely impractical or pointless attack, and there's probably much easier ways to attack the exposed service, but I don't know enough about security to judge that. Also I don't know what packet construction would be sufficiently careful. But it seems like a possible new concern that's introduced when using UDP in this context.) -- Philip Taylor exc...@gmail.com
[whatwg] 'Main Part of the Content' Idiom
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
Re: [whatwg] Installable web apps
On May 26, 2010, at 20:10, Aaron Boodman wrote: This isn't really the point of this mail, but I just want to point out that there are more differences between wgt and crx than the format of the manifest file. The most important is that the identify of a crx file is a public key, and all crx files are self-signed by their key. This makes a crx file's identity unforgeable. .wgt supports signing, too, but as with Sun .jar or Mozilla .xpi the signing proves that the .wgt came from the entity that the private key belongs to as certified by PKI--as opposed to proving without PKI that it came from the same source as the previous version of the .wgt. After googling around a bit, I was unable to find a signed .crx file for analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism documented somewhere? .wgt reinvents the .jar signing wheel by the basic idea of .jar signing with XML Signatures. (Note that I am not in any way implying that PKI were better. If Google can actually get extension authors to sign their extensions on average and proving that extension updates came from the same source as the previous version, that's a pretty big win over the Firefox extension signing situation. In principle, Firefox extensions can be signed to the stronger level of proving who signed them as opposed to proving just same as before, but in practice, virtually no one--not even Mozilla Labs--signs Firefox extensions, so it doesn't help much that the level of proof would be stronger if signed.) The source of our support for packaged applications is that we have gotten a lot of feedback from developers that find packages a very convenient way to develop applications that work offline. I think the reason is that packages are conceptually much simpler than app caches. That said, I think this is mainly a lack of good tool support for app cache and good documentation, and I think it can eventually be overcome. I see. For now, I would like to focus on live web apps, not packaged local apps. Great. I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design. A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To install a Web application, the user would navigate to the app's URL and create an application bookmark. For Chrome this isn't the UX we want. We want users to click a link in the content area and be presented with an install dialog. We think that going to something in the browser to applicationify a web app is too indirect and that many users will not get it. That said, I think there is room to support multiple models of installation (or bookmarking, or whatever you want to call it), though. Why don't you want the UX of the applicatinification process starting from browser chrome? Screen real estate reasons? Expectation or research showing that users don't understand the difference anyway? Don't you need an annoying This site is trying to applicationify itself. Allow or Deny? piece of UI if the site can start the process? If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, use link rel=something to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names. We have a growing set of metadata you're trying to link to: - Icons Mobile Safari and, AFAIK, the default Android browser already use use link rel=apple-touch-icon for this, so it seems to me the link cat is already out of the bag. - Application name (you didn't mention this, but I think it is nice to have distinct from the title, which is often overloaded with status information) As Lachy mentioned, there's already in-document syntax for this: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta-application-name I'm not aware of anyone implementing it, though. Another one that we would like in Chrome is a path prefix for the app. This is to handle the case of applications like Google Reader which are on http://www.google.com/reader. How does giving
Re: [whatwg] 'Main Part of the Content' Idiom
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.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
Re: [whatwg] 'Main Part of the Content' Idiom
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.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.uk
Re: [whatwg] 'Main Part of the Content' Idiom
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.ukwrote: 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.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.uk
Re: [whatwg] 'Main Part of the Content' Idiom
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.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.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.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.uk
Re: [whatwg] 'Main Part of the Content' Idiom
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.ukwrote: 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.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.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.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.uk
Re: [whatwg] 'Main Part of the Content' Idiom
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.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.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.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.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
Re: [whatwg] 'Main Part of the Content' Idiom
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.ukwrote: 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.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.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.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.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.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.uk
Re: [whatwg] 'Main Part of the Content' Idiom
The purpose of all the new tags, is so the machine can figure out what is NOT main content, and assume everything else is. With proper use of sectioning and aside as well as header and footers this can be mostly achieved today. On 4/06/2010, at 5: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.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.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.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.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.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.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.uk
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, Jun 4, 2010 at 9:39 AM, Daniel Persson danielperssondel...@gmail.com 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. Authors can either use aside to mark up all the irrelevant stuff on their page that isn't main content, or they can wrap the main content in an article (not ideal, but workable). ~TJ
[whatwg] Canvas putImageData - Can we scale?
Hi, I wonder if this is the correct place to post this but I cannot find any resources online as canvas is so new. After grabbing some image data from a canvas with the getImageData call, I cannot find a way to put the image data onto a canvas scaled down. If I use the canvas scale function and then put the image data, no scaling occurs. Is there any way to scale with putImageData? If not I think it would be a useful addition to the specification. I can imagine many situations where copying a section of the canvas and applying scaling before pasting it back to the canvas would be useful! Thanks, Rob Evans CTO mtn-i LTD
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] Canvas putImageData - Can we scale?
On Jun 4, 2010, at 10:05 AM, Rob Evans wrote: Hi, I wonder if this is the correct place to post this but I cannot find any resources online as canvas is so new. Canvas isn't new -- it's at least 4 or 5 years old, and has been in the html5 spec for at least 2 or 3 of those years -- I believe the MDC has some of the best API documentation (at least in terms of providing examples of how the APIs are used.) After grabbing some image data from a canvas with the getImageData call, I cannot find a way to put the image data onto a canvas scaled down. If I use the canvas scale function and then put the image data, no scaling occurs. Is there any way to scale with putImageData? No. The ImageData API documentation is very clear on this, and has not changed substantively in a few years now. get/putImageData are not effected by the current CTM. If not I think it would be a useful addition to the specification. I can imagine many situations where copying a section of the canvas and applying scaling before pasting it back to the canvas would be useful! You shouldn't be using ImageData to do this -- CanvasRenderingContext2D.drawImage supports canvas elements, and has well defined semantics for drawing the contents of a canvas element into its own context -- in addition to supporting non-identity CTMs this is also likely quite a bit faster in the identity case than an imagedata based approach. Is there some specific reason you want to use the ImageData API? --Oliver Thanks, Rob Evans CTO mtn-i LTD
Re: [whatwg] Canvas putImageData - Can we scale?
1: My bad. 2: Fair enough. 3: Thanks, I had totally skipped the extra parameters available on the drawImage function... oops. I think I'll blog it so anyone else who skim-reads the MDC will find my mistake on google when they search! From: Oliver Hunt [mailto:oli...@apple.com] Sent: 04 June 2010 18:40 To: Rob Evans Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Canvas putImageData - Can we scale? On Jun 4, 2010, at 10:05 AM, Rob Evans wrote: Hi, I wonder if this is the correct place to post this but I cannot find any resources online as canvas is so new. Canvas isn't new -- it's at least 4 or 5 years old, and has been in the html5 spec for at least 2 or 3 of those years -- I believe the MDC has some of the best API documentation (at least in terms of providing examples of how the APIs are used.) After grabbing some image data from a canvas with the getImageData call, I cannot find a way to put the image data onto a canvas scaled down. If I use the canvas scale function and then put the image data, no scaling occurs. Is there any way to scale with putImageData? No. The ImageData API documentation is very clear on this, and has not changed substantively in a few years now. get/putImageData are not effected by the current CTM. If not I think it would be a useful addition to the specification. I can imagine many situations where copying a section of the canvas and applying scaling before pasting it back to the canvas would be useful! You shouldn't be using ImageData to do this -- CanvasRenderingContext2D.drawImage supports canvas elements, and has well defined semantics for drawing the contents of a canvas element into its own context -- in addition to supporting non-identity CTMs this is also likely quite a bit faster in the identity case than an imagedata based approach. Is there some specific reason you want to use the ImageData API? --Oliver Thanks, Rob Evans CTO mtn-i LTD
Re: [whatwg] Installable web apps
On Fri, Jun 4, 2010 at 4:58 AM, Henri Sivonen hsivo...@iki.fi wrote: After googling around a bit, I was unable to find a signed .crx file for analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism documented somewhere? .wgt reinvents the .jar signing wheel by the basic idea of .jar signing with XML Signatures. All .crx files are signed - they're just a zip with the public key and signature appended on to them. The chrome extensions gallery has lots of them: https://chrome.google.com/extensions For developers who choose to use it, the gallery takes care of generating/storing the private key and signing new versions. They just upload a plain zip file with their extension's resources. For those who want to do this themselves, the developer tools on the chrome://extensions page inside chrome itself lets you create a signed .crx file. You can find some documentation here: http://code.google.com/chrome/extensions/packaging.html And here's the browser code to create .crx files: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_creator.cc http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_creator.cc
Re: [whatwg] Installable web apps
On Fri, Jun 4, 2010 at 4:58 AM, Henri Sivonen hsivo...@iki.fi wrote: On May 26, 2010, at 20:10, Aaron Boodman wrote: This isn't really the point of this mail, but I just want to point out that there are more differences between wgt and crx than the format of the manifest file. The most important is that the identify of a crx file is a public key, and all crx files are self-signed by their key. This makes a crx file's identity unforgeable. .wgt supports signing, too, but as with Sun .jar or Mozilla .xpi the signing proves that the .wgt came from the entity that the private key belongs to as certified by PKI--as opposed to proving without PKI that it came from the same source as the previous version of the .wgt. After googling around a bit, I was unable to find a signed .crx file for analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism documented somewhere? .wgt reinvents the .jar signing wheel by the basic idea of .jar signing with XML Signatures. (Note that I am not in any way implying that PKI were better. If Google can actually get extension authors to sign their extensions on average and proving that extension updates came from the same source as the previous version, that's a pretty big win over the Firefox extension signing situation. In principle, Firefox extensions can be signed to the stronger level of proving who signed them as opposed to proving just same as before, but in practice, virtually no one--not even Mozilla Labs--signs Firefox extensions, so it doesn't help much that the level of proof would be stronger if signed.) Every crx file is signed. The signature and public key are part of the zip file itself, just after the signature. The zip format allows extra data there. When you took apart those crx files, if you used 'unzip' from the command line, you may have seen 'Ignoring xx bytes of extra data...'. That was the public key and signature being discarded :). For the most part developers don't know or care about the details of how signing works. We tried really hard to make it something that just happens as part of developing your extension. For users who host on our gallery, it is totally hidden. They just upload zip files and the the gallery manages the key. For users who self-host, they will be aware that there is something called a key file that contains gibberish, which they need to keep safe and need to use each time they package their extension. You can get a feel for what this is like from a developer's point of view here: http://code.google.com/chrome/extensions/packaging.html If you're interested in the actual format, it has been a longstanding todo to document it precisely :-/ But it is basically: zip headercrx versionkeysignaturezip data. Somebody created a tiny ruby script that does it, here: http://github.com/Constellation/crxmake/blob/master/lib/crxmake.rb#-196 I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design. A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To install a Web application, the user would navigate to the app's URL and create an application bookmark. For Chrome this isn't the UX we want. We want users to click a link in the content area and be presented with an install dialog. We think that going to something in the browser to applicationify a web app is too indirect and that many users will not get it. That said, I think there is room to support multiple models of installation (or bookmarking, or whatever you want to call it), though. Why don't you want the UX of the applicatinification process starting from browser chrome? Screen real estate reasons? Expectation or research showing that users don't understand the difference anyway? Our experience is that: a) Users typically don't see this kind of UI in the browser chrome. The easy example is the feed badge in the URL bar, which fails with normal people. To make this more discoverable, browsers ended up supporting navigating directly to a feed file to initiate feedification. b) Because users miss the browser UI, developers end up wanting to help and end up resorting to terrible things like putting a big arrow in their content that says click over there . Don't you need an annoying This site is trying to applicationify itself. Allow or Deny? piece of UI if the site can start the
Re: [whatwg] 'Main Part of the Content' Idiom
On 2010-06-04 18:39, 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.
Hmm! It is a valid point actually.
Oh and here is some food for though. This works in all latest browsers.
Opera and Firefox have same behavior, while Chrome is a tad different,
and as IE is unable to style unknown tags sadly.
!doctype html
html
head
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
/head
aside
Just testing aside outside body!
/aside
body
article
Main part of article.
/article
/body
/html
As you can see the aside is outside the body, all latest browsers seem
to handle this pretty fine.
http://validator.w3.org/ on the other hand gives the error /Line 12,
Column 6/: body start tag found but the body element is already open.|
body**|
Now, either that is a bug in the validator, or the body is automatic.
And sure enough, removing the body and /body tags the document
validates, and none of the browsers behave differently at all.
Is the body tag optional or could even be redundant in HTML5 ?
I don't mind really, as currently I only use body to put all the other
tags inside, so not having to use the body tag at all would be welcome,
though I suspect a lot of legacy things rely on the body tag.
--
Roger Rescator Hågensen.
Freelancer - http://EmSai.net/
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, Jun 4, 2010 at 12:58 PM, Roger Hågensen resca...@emsai.net wrote:
On 2010-06-04 18:39, 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.
Hmm! It is a valid point actually.
Oh and here is some food for though. This works in all latest browsers.
Opera and Firefox have same behavior, while Chrome is a tad different, and
as IE is unable to style unknown tags sadly.
!doctype html
html
head
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
/head
aside
Just testing aside outside body!
/aside
body
article
Main part of article.
/article
/body
/html
As you can see the aside is outside the body, all latest browsers seem to
handle this pretty fine.
http://validator.w3.org/ on the other hand gives the error Line 12, Column
6: body start tag found but the body element is already open. body
Now, either that is a bug in the validator, or the body is automatic.
And sure enough, removing the body and /body tags the document
validates, and none of the browsers behave differently at all.
Is the body tag optional or could even be redundant in HTML5 ?
body is optional. It automatically gets added as soon as the parser
sees an element that doesn't belong in the head. (The head is
optional too, as is the html.) So the aside triggers a body
element to be created and opened, and then later explicit body tags
get dropped.
I don't mind really, as currently I only use body to put all the other
tags inside, so not having to use the body tag at all would be welcome,
though I suspect a lot of legacy things rely on the body tag.
No browser depends on you using the body element explicitly. It's
perfectly fine to write your document like this:
!doctype html
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
aside
Just testing aside outside body!
/aside
article
Main part of article.
/article
The title and style get auto-wrapped in a head, the aside and
article get auto-wrapped in a body, and the whole thing below the
doctype gets auto-wrapped in an html.
~TJ
Re: [whatwg] 'Main Part of the Content' Idiom
On 2010-06-04 22:03, Tab Atkins Jr. wrote:
On Fri, Jun 4, 2010 at 12:58 PM, Roger Hågensenresca...@emsai.net wrote:
...
As you can see the aside is outside the body, all latest browsers seem to
handle this pretty fine.
http://validator.w3.org/ on the other hand gives the error Line 12, Column
6: body start tag found but the body element is already open.body
Now, either that is a bug in the validator, or the body is automatic.
And sure enough, removing thebody and/body tags the document
validates, and none of the browsers behave differently at all.
Is the body tag optional or could even be redundant in HTML5 ?
body is optional. It automatically gets added as soon as the parser
sees an element that doesn't belong in thehead. (Thehead is
optional too, as is thehtml.) So theaside triggers abody
element to be created and opened, and then later explicitbody tags
get dropped.
I don't mind really, as currently I only use body to put all the other
tags inside, so not having to use the body tag at all would be welcome,
though I suspect a lot of legacy things rely on the body tag.
No browser depends on you using thebody element explicitly. It's
perfectly fine to write your document like this:
!doctype html
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
aside
Just testing aside outside body!
/aside
article
Main part of article.
/article
Thetitle andstyle get auto-wrapped in ahead, theaside and
article get auto-wrapped in abody, and the whole thing below the
doctype gets auto-wrapped in anhtml.
Hmm! Intriguing. That is way cleaner than the container wrappers.
What browsers/engines behaves like that?
Does all HTML 4.01+ compliant browsers behave like this?
Roger.
--
Roger Rescator Hågensen.
Freelancer - http://EmSai.net/
[whatwg] no body wants to stay in touch on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - no body no body Student at Universidad de Montevideo Uruguay Confirm that you know no body https://www.linkedin.com/e/isd/1361348824/0ScZquf7/ -- (c) 2010, LinkedIn Corporation
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, Jun 4, 2010 at 1:16 PM, Roger Hågensen resca...@emsai.net wrote:
On 2010-06-04 22:03, Tab Atkins Jr. wrote:
On Fri, Jun 4, 2010 at 12:58 PM, Roger Hågensenresca...@emsai.net
wrote:
...
As you can see the aside is outside the body, all latest browsers seem to
handle this pretty fine.
http://validator.w3.org/ on the other hand gives the error Line 12,
Column
6: body start tag found but the body element is already open.body
Now, either that is a bug in the validator, or the body is automatic.
And sure enough, removing thebody and/body tags the document
validates, and none of the browsers behave differently at all.
Is the body tag optional or could even be redundant in HTML5 ?
body is optional. It automatically gets added as soon as the parser
sees an element that doesn't belong in thehead. (Thehead is
optional too, as is thehtml.) So theaside triggers abody
element to be created and opened, and then later explicitbody tags
get dropped.
I don't mind really, as currently I only use body to put all the other
tags inside, so not having to use the body tag at all would be welcome,
though I suspect a lot of legacy things rely on the body tag.
No browser depends on you using thebody element explicitly. It's
perfectly fine to write your document like this:
!doctype html
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
aside
Just testing aside outside body!
/aside
article
Main part of article.
/article
Thetitle andstyle get auto-wrapped in ahead, theaside and
article get auto-wrapped in abody, and the whole thing below the
doctype gets auto-wrapped in anhtml.
Hmm! Intriguing. That is way cleaner than the container wrappers.
What browsers/engines behaves like that?
Does all HTML 4.01+ compliant browsers behave like this?
All browsers that you could possibly care about (any FF, Safari,
Chrome, Opera, or IE produced in the last decade) should act like
that. That's why it got specified - when everyone agrees on behavior,
it's a good thing to figure that out and standardize it. ^_^
~TJ
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, 2010-06-04 at 13:28 -0700, Tab Atkins Jr. wrote:
On Fri, Jun 4, 2010 at 1:16 PM, Roger Hågensen resca...@emsai.net wrote:
On 2010-06-04 22:03, Tab Atkins Jr. wrote:
On Fri, Jun 4, 2010 at 12:58 PM, Roger Hågensenresca...@emsai.net
wrote:
...
As you can see the aside is outside the body, all latest browsers seem to
handle this pretty fine.
http://validator.w3.org/ on the other hand gives the error Line 12,
Column
6: body start tag found but the body element is already open.body
Now, either that is a bug in the validator, or the body is automatic.
And sure enough, removing thebody and/body tags the document
validates, and none of the browsers behave differently at all.
Is the body tag optional or could even be redundant in HTML5 ?
body is optional. It automatically gets added as soon as the parser
sees an element that doesn't belong in thehead. (Thehead is
optional too, as is thehtml.) So theaside triggers abody
element to be created and opened, and then later explicitbody tags
get dropped.
I don't mind really, as currently I only use body to put all the other
tags inside, so not having to use the body tag at all would be welcome,
though I suspect a lot of legacy things rely on the body tag.
No browser depends on you using thebody element explicitly. It's
perfectly fine to write your document like this:
!doctype html
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
aside
Just testing aside outside body!
/aside
article
Main part of article.
/article
Thetitle andstyle get auto-wrapped in ahead, theaside and
article get auto-wrapped in abody, and the whole thing below the
doctype gets auto-wrapped in anhtml.
Hmm! Intriguing. That is way cleaner than the container wrappers.
What browsers/engines behaves like that?
Does all HTML 4.01+ compliant browsers behave like this?
All browsers that you could possibly care about (any FF, Safari,
Chrome, Opera, or IE produced in the last decade) should act like
that. That's why it got specified - when everyone agrees on behavior,
it's a good thing to figure that out and standardize it. ^_^
~TJ
And I'm guessing Fx too?
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [whatwg] 'Main Part of the Content' Idiom
On 2010-06-04 resca...@emsai.net wrote:
On 2010-06-04 22:03, Tab Atkins Jr. wrote:
No browser depends on you using thebody element explicitly. It's
perfectly fine to write your document like this:
!doctype html
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
aside
Just testing aside outside body!
/aside
article
Main part of article.
/article
Thetitle andstyle get auto-wrapped in ahead, theaside and
article get auto-wrapped in abody, and the whole thing below the
doctype gets auto-wrapped in anhtml.
Hmm! Intriguing. That is way cleaner than the container wrappers.
What browsers/engines behaves like that?
Does all HTML 4.01+ compliant browsers behave like this?
As I understand it the opening and closing tags of the html, head and
body elements are optional so that whenever content that belongs in
one of those elements (such as text) is encountered it's automatically
opened. Same as p elements get closed when block content is encountered
(in HTML 4 that is). This is fully specified and documented and is in the
DTD.
This is valid HTML 4.
is in fact a valid HTML file with an empty head.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 10:30 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 6/3/10, TAMURA, Kent tk...@chromium.org wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. That's about input type=hidden No, it's not. Look at the definition of being rendered: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#being-rendered It gives the hidden *attribute* (not type) as an example.
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, Jun 4, 2010 at 4:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
No browser depends on you using the body element explicitly. It's
perfectly fine to write your document like this:
!doctype html
titleTest/title
style
aside {border:1px solid #bf;white-space:nowrap;}
/style
aside
Just testing aside outside body!
/aside
article
Main part of article.
/article
It's unwise to omit body unless you can guarantee that the first
element in the body will actually trigger the end of the head. In
your case, I believe that at least IE will put aside and article
in the head, because it doesn't recognize them as only belonging in
the body. (It seems like the HTML5 parser does put it in the body --
although as far as I can tell, this means we can never introduce new
elements that can go in the head.)
On Fri, Jun 4, 2010 at 4:36 PM, bjartur svartma...@gmail.com wrote:
As I understand it the opening and closing tags of the html, head and
body elements are optional so that whenever content that belongs in
one of those elements (such as text) is encountered it's automatically
opened. Same as p elements get closed when block content is encountered
(in HTML 4 that is). This is fully specified and documented and is in the
DTD.
This is valid HTML 4.
is in fact a valid HTML file with an empty head.
Something seems to have been left out of your e-mail, but anyway, a
valid HTML file cannot have an empty head. All HTML documents must
have a title element, which must be contained in a head. This was
true in HTML 4.01 just as it is in HTML5.
Re: [whatwg] 'Main Part of the Content' Idiom
On Fri, 2010-06-04 at 14:47 -0700, Tab Atkins Jr. wrote: On Fri, Jun 4, 2010 at 1:32 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 13:28 -0700, Tab Atkins Jr. wrote: All browsers that you could possibly care about (any FF, Safari, Chrome, Opera, or IE produced in the last decade) should act like that. That's why it got specified - when everyone agrees on behavior, it's a good thing to figure that out and standardize it. ^_^ ~TJ And I'm guessing Fx too? That would be the FF I referred to. Firefox lost the battle to be abbreviated as Fx a *long* time ago. ^_^ ~TJ Someone should tell Mozilla about it then, because they still prefer Fx ;) http://www.mozilla.com/en-US/firefox/releases/1.5.html Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] bubbling events on labels
I have different behavior in browsers with the checked state of a checkbox input element. I have filed a ticket in Webkit and I am looking after some advice/suggestion about the correct behavior expected from this HTML: label input type=checkbox a href=#Enable/a /label It seems Safari/Chrome are discarding the click bubbling at the link level, thus never reaching the label and not toggling the checkbox. The behavior in Firefox/Opera and in Safari/Chrome is different and the checkbox is correctly checked (as I would have expected). Should a click on the link make the input checked ? Thank you in advance, sincerely Diego Perini
Re: [whatwg] bubbling events on labels
On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini diego.per...@gmail.com wrote: I have different behavior in browsers with the checked state of a checkbox input element. I have filed a ticket in Webkit and I am looking after some advice/suggestion about the correct behavior expected from this HTML: label input type=checkbox a href=#Enable/a /label It seems Safari/Chrome are discarding the click bubbling at the link level, thus never reaching the label and not toggling the checkbox. The behavior in Firefox/Opera and in Safari/Chrome is different and the checkbox is correctly checked (as I would have expected). Should a click on the link make the input checked ? As far as I can tell, section 3.5.2.1.7 (Interactive Content) specifies that clicking the link in that situation should activate the link and not toggle the checkbox. ~TJ
Re: [whatwg] bubbling events on labels
On Fri, 2010-06-04 at 15:21 -0700, Tab Atkins Jr. wrote: On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini diego.per...@gmail.com wrote: I have different behavior in browsers with the checked state of a checkbox input element. I have filed a ticket in Webkit and I am looking after some advice/suggestion about the correct behavior expected from this HTML: label input type=checkbox a href=#Enable/a /label It seems Safari/Chrome are discarding the click bubbling at the link level, thus never reaching the label and not toggling the checkbox. The behavior in Firefox/Opera and in Safari/Chrome is different and the checkbox is correctly checked (as I would have expected). Should a click on the link make the input checked ? As far as I can tell, section 3.5.2.1.7 (Interactive Content) specifies that clicking the link in that situation should activate the link and not toggle the checkbox. ~TJ I do wonder though in what situation you would ever have that sort if code layout and want the checkbox selected when the link is clicked. Clicking the link will navigate away anyway, making the form element useless in that context. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] bubbling events on labels
On Fri, Jun 4, 2010 at 3:24 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 15:21 -0700, Tab Atkins Jr. wrote: On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini diego.per...@gmail.com wrote: I have different behavior in browsers with the checked state of a checkbox input element. I have filed a ticket in Webkit and I am looking after some advice/suggestion about the correct behavior expected from this HTML: label input type=checkbox a href=#Enable/a /label It seems Safari/Chrome are discarding the click bubbling at the link level, thus never reaching the label and not toggling the checkbox. The behavior in Firefox/Opera and in Safari/Chrome is different and the checkbox is correctly checked (as I would have expected). Should a click on the link make the input checked ? As far as I can tell, section 3.5.2.1.7 (Interactive Content) specifies that clicking the link in that situation should activate the link and not toggle the checkbox. I do wonder though in what situation you would ever have that sort if code layout and want the checkbox selected when the link is clicked. Clicking the link will navigate away anyway, making the form element useless in that context. Not if the link is just to a target on the page, like it is in the example given. ~TJ
Re: [whatwg] WebSockets: UDP
On Fri, Jun 4, 2010 at 4:19 AM, James May wha...@fowlsmurf.net wrote: Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work? No, DCCP is much newer than most NAT hardware in operation. When a client user agent is sending UDP, client-initiated TCP streams such as HTTP or HTTPS persistent connections for all data from the server including packet acknowledgment is likely to be the most reliable. Bandwidth from the server to the client is usually greater than or equal to bandwidth from client to server.
