Re: [whatwg] Why won't you let us make our own HTML5 browsers?
Hi Ian, Thank you for taking the time to follow up. Some of my comments do seem a little immature in hindsight and I tend to agree now that adding a lot of these suggestions to the HTML spec. would make little difference. I am exploring options to reduce the potential for UA state leaks but do not have anything concrete to propose yet. If you care to see some ideas being explored then please see: http://www.w3.org/community/pua/wiki/Draft I could certainly use some feedback. Perhaps someday it will be possible to propose some extensions to better secure the UA state such as new iframe sandbox flags etc. I grew up with computers being personal and private places and we only shared data explicitly. I wince when I see children using the modern web browsers as a platform for computing - knowing the visibility external resources have over their actions. I'll do what I can to try and provide a more secure and private UA option. cheers Fred
Re: [whatwg] Encoding: API
On Thu, Oct 18, 2012 at 4:16 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Oct 18, 2012 at 3:54 AM, Anne van Kesteren ann...@annevk.nl wrote: * TextDecoder.decode()'s view argument is no longer optional. Why should it be? It buffers the EOF byte when in streaming mode, eg. when the last byte of the stream is a UTF-8 continuation byte, so any encode errors are triggered. * TextEncoder.encode()'s input argument is no longer nullable. Again, why should it be? Likewise for encoding, to flush errors for trailing high surrogates. I made these arguments optional now (and named them both input). Note however that the way you get the EOF byte/EOF code point is by omitting the dictionary (whose stream member defaults to false), but I can see how not passing any arguments as a final call is convenient. https://github.com/whatwg/encoding/commit/39a201a5cdf43be3d49c6bac7952a0ecb225886b I also raised the issue of whether TextEncoder should really support utf-16/utf-16be as the encoding standard tries to deprecate non-utf-8 encodings. The whole point of this API is to support legacy file formats that use other encodings. (It's probably questionable to not support other encodings, too, eg. filenames in ZIP file headers, but starting out with Unicode is fine.) I thought it was mostly about reading legacy formats, but fair enough. -- http://annevankesteren.nl/
Re: [whatwg] Features for responsive Web design
If it is really necessary to support this case then perhaps both the image width and the the native pixel breakpoints could be specified in the srcset. Then srcset=low.jpg 10w 20w, hi.jpg 20w 40w, huge.jpg 30w would mean: low.jpg is 10 pixels wide and use it if the native pixel width of the image box is less than or equal to 20, hi.jpg is 20 pixels wide and use it if the native pixel width of the image box is less than or equal to 40, huge.jpg is 30 pixels wide and use it if the native pixel width of the image box is less than greater than 40 pixles The default break points could be the image sizes, and would typically not be needed. The first image could be the 1x density image, allowing the browser to determine the image box size if not otherwise specified and this could be done before loading the image. This approach may be more natural for a fluid design. cheers Fred Date: Thu, 18 Oct 2012 08:31:57 +0200 From: i...@anselm-hannemann.com To: freda...@live.com CC: whatwg@lists.whatwg.org; odi...@opera.com Subject: Re: [whatwg] Features for responsive Web design Am Donnerstag, 18. Oktober 2012 um 04:05 schrieb Fred Andrews: This is good point. Could I just clarify my understanding with an example: Given a thumbnail image with srcset: srcset=low.jpg 20w, hi.jpg 40w, huge.jpg 80w The webpage may want to have the browser scale the 20w image to say 50px without the browser deciding that the 40w image is more appropriate? Perhaps it would be realistic for this case to simply not be supported. srcset cannot support this case. This is one case (of many) why we suggested picture-element. Authors have the alternative option of using an encoding with a lower quality to reduce the image file size, rather than supplying a low resolution image that the browser scales up. Perhaps when the file size is far more important than image quality a single image would suffice anyway. I don't think that is an answer for such a problem. It is how you would solve it today. Not how you want to solve it. Cheers -Anselm cheers Fred To: whatwg@lists.whatwg.org (mailto:whatwg@lists.whatwg.org) Date: Mon, 15 Oct 2012 18:40:21 +0200 From: odi...@opera.com (mailto:odi...@opera.com) Subject: Re: [whatwg] Features for responsive Web design On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch (mailto:derer...@gmx.ch) wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Mat, have taken your advice and made an initial draft of a use case/rationale document: http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction feedback welcome! regards SteveF On 18 October 2012 22:27, Mathew Marquis m...@matmarquis.com wrote: On Oct 18, 2012, at 2:36 PM, Ian Hickson wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. Off-topic, but just for the record: there was no expectation that the RICG’s proposal would simply be accepted wholesale, for obvious reasons—just that we would be able to collaborate with the WHATWG on it. It wouldn’t have made much sense for us to call it a “proposal” otherwise, after all. :) On-topic: the `main` class/ID pattern is an exceedingly common one, for sure. I use it all the time myself, in conjunction with `role=main`. I was originally of the mind that the role of “primary content” was served by the first `article` element within the document, but where the first `article` just represents the first sectioned stand-alone content in the document, it could be something like an infographic — capable of functioning independent of the surrounding document, but not the entirety of the primary content. Given the clear meaning of the proposed element, the low barrier to adoption by web developers, and the potential benefits this could have in terms of syndication and accessibility: it certainly sounds interesting! The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step! -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] checksum attribute in a href tag
On Fri, Oct 19, 2012 at 1:50 PM, A. Rauschenbach rauschenb...@annuo.de wrote: I'm sick of coping the checksum of important files by hand or QR-code to the download manager or console. To solve the problem I suggest a checksum attribute in the a href tag. example: a href=http://example.com/important.file; checksum=MD5:32c3675211199b671fbca1304d819289;SHA1:6e1ddeede3979c953788a3499616af35ee5fd772download/a Another advantage is that your visitors (browser) can verify that the document (e.g. a pdf) you linked to is still the same. If you serve important files over HTTP without TLS I don't think a checksum is going to help anyone much. We did have something similar to this, but it got dropped: http://html5.org/r/7434 -- http://annevankesteren.nl/
Re: [whatwg] checksum attribute in a href tag
A. Rauschenbach rauschenb...@annuo.de schrieb am Fri, 19 Oct 2012 13:50:04 +0200: I'm sick of coping the checksum of important files by hand or QR-code to the download manager or console. To solve the problem I suggest a checksum attribute in the a href tag. It seems that problem is solved at the HTTP level with RFC 1864: http://tools.ietf.org/html/rfc1864 Another advantage is that your visitors (browser) can verify that the document (e.g. a pdf) you linked to is still the same. Cool URIs should not change. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] checksum attribute in a href tag
Am 2012-10-19 14:01, schrieb Nils Dagsson Moskopp: It seems that problem is solved at the HTTP level with RFC 1864: http://tools.ietf.org/html/rfc1864 If I get it right this works fine if you serve it from your server, but not if you link to foreign server. Another advantage is that your visitors (browser) can verify that the document (e.g. a pdf) you linked to is still the same. Cool URIs should not change. A changing URI isn't the problem. In that case you get a 404. The problem is when the URI stays the same but the content behind it changes. (especially when the content is not on your server)
Re: [whatwg] checksum attribute in a href tag
If you serve important files over HTTP without TLS I don't think a checksum is going to help anyone much. With important I meant the file as to work right here and right now not any security issues.
Re: [whatwg] Encoding: API
On Thu, Oct 18, 2012 at 1:49 AM, Anne van Kesteren ann...@annevk.nl wrote:
I added the API to the Encoding Standard:
http://encoding.spec.whatwg.org/#api
Feedback welcome. I suppose we might want to write an introduction for it
too.
Thanks, Anne! Excellent cleanup, too.
On Thu, Oct 11, 2012 at 6:37 PM, Joshua Bell jsb...@chromium.org wrote:
It sounds like there are several desirable behaviors:
1. ignore BOM handling entirely (BOM would be present in output, or
fatal)
2. if matching BOM, consume; otherwise, ignore (mismatching BOM would be
present in output, or fatal)
3. switch encoding based on BOM (any of UTF-8, UTF-16LE, UTF-16BE)
4. switch encoding based on BOM if-and-only-if UTF-16 explicitly
specified, and only to one of the UTF-16 variants
I went with supporting just 2 for now. 4 seems weird.
As per IRC discussion, if someone wants to implement this functionality it
is fairly simple from script.
On Thu, Oct 18, 2012 at 11:24 PM, Anne van Kesteren ann...@annevk.nlwrote:
On Thu, Oct 18, 2012 at 4:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Oct 18, 2012 at 3:54 AM, Anne van Kesteren ann...@annevk.nl
wrote:
* TextDecoder.decode()'s view argument is no longer optional. Why should
it be?
It buffers the EOF byte when in streaming mode, eg. when the last byte
of
the stream is a UTF-8 continuation byte, so any encode errors are
triggered.
* TextEncoder.encode()'s input argument is no longer nullable. Again,
why should it be?
Likewise for encoding, to flush errors for trailing high surrogates.
I made these arguments optional now (and named them both input). Note
however that the way you get the EOF byte/EOF code point is by
omitting the dictionary (whose stream member defaults to false), but I
can see how not passing any arguments as a final call is convenient.
https://github.com/whatwg/encoding/commit/39a201a5cdf43be3d49c6bac7952a0ecb225886b
Yes, purely convenience. Otherwise you'd need to call:
decoder.decode(buffer1, {stream: true});
decoder.decode(buffer2, {stream: true});
decoder.decode(new Uint8Array());
I also raised the issue of whether TextEncoder should really support
utf-16/utf-16be as the encoding standard tries to deprecate non-utf-8
encodings.
The whole point of this API is to support legacy file formats that use
other
encodings. (It's probably questionable to not support other encodings,
too,
eg. filenames in ZIP file headers, but starting out with Unicode is
fine.)
I thought it was mostly about reading legacy formats, but fair enough.
Jonas did a straw poll via Twitter about whether enoding to UTF-16 was
needed, and received positive feedback.
Re: [whatwg] Character-encoding-related threads
On Fri, 19 Oct 2012, Jukka K. Korpela wrote: Are there any situations that this doesn't handle where it would be legitimate to omit a title element? Perhaps the simplest case is an HTML document that is only meant to be displayed inside an inline frame and containing, say, just a numeric table. It is not meant to be found and indexed by search engines, it is not supposed to be rendered as a standalone document with a browser top bar (or equivalent) showing its title, etc. The initial intent of such a document may be to only display it in a frame, but since it's independently addressable, nothing stops a search engine from referencing it, a user from bookmarking it, etc. So I don't think that's an example of where omitting title is a good idea. The current wording looks OK to me, and it to me, it says that a title is not needed when the document is not to be used out of context: The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results. http://www.whatwg.org/specs/web-apps/current-work/#the-title-element That isn't what that says. Please make sure never to read between the lines when reading a specification. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] checksum attribute in a href tag
On Fri, 19 Oct 2012, A. Rauschenbach wrote: I'm sick of coping the checksum of important files by hand or QR-code to the download manager or console. To solve the problem I suggest a checksum attribute in the a href tag. example: a href=http://example.com/important.file; checksum=MD5:32c3675211199b671fbca1304d819289;SHA1:6e1ddeede3979c953788a3499616af35ee5fd772download/a Another advantage is that your visitors (browser) can verify that the document (e.g. a pdf) you linked to is still the same. What is the attack scenario you are trying to avoid? Without a discussion of what problem you're trying to solve, it's unclear how to evaluate the proposal. The idea of a hash= or checksum= attribute on a href has come up before -- about once a year, as far as I can tell! -- but it's always been found lacking in one way or another. e.g.: http://lists.w3.org/Archives/Public/public-whatwg-archive/2006Nov/thread.html#msg233 http://lists.w3.org/Archives/Public/public-whatwg-archive/2007Jul/0049.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Dec/0376.html (in the third one, search for fingerprint.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Character-encoding-related threads
2012-10-19 19:33, Ian Hickson wrote: On Fri, 19 Oct 2012, Jukka K. Korpela wrote: Are there any situations that this doesn't handle where it would be legitimate to omit a title element? Perhaps the simplest case is an HTML document that is only meant to be displayed inside an inline frame and containing, say, just a numeric table. It is not meant to be found and indexed by search engines, it is not supposed to be rendered as a standalone document with a browser top bar (or equivalent) showing its title, etc. The initial intent of such a document may be to only display it in a frame, but since it's independently addressable, nothing stops a search engine from referencing it, a user from bookmarking it, etc. So I don't think that's an example of where omitting title is a good idea. Anyone who bookmarks a document that was not meant to be bookmarked should accept the consequences. But it seems that it is pointless to present any situations where it would be legitimate to omit a title element, since you are prepared to refuting any possible example by presenting how things could be different from the scenario given. The title element represents the document's title or name. Yet you seem to deny, a priori, the possibility that a document does not need a title or a name. Yucca
Re: [whatwg] Character-encoding-related threads
On Fri, 19 Oct 2012, Jukka K. Korpela wrote: 2012-10-19 19:33, Ian Hickson wrote: On Fri, 19 Oct 2012, Jukka K. Korpela wrote: Are there any situations that this doesn't handle where it would be legitimate to omit a title element? Perhaps the simplest case is an HTML document that is only meant to be displayed inside an inline frame and containing, say, just a numeric table. It is not meant to be found and indexed by search engines, it is not supposed to be rendered as a standalone document with a browser top bar (or equivalent) showing its title, etc. The initial intent of such a document may be to only display it in a frame, but since it's independently addressable, nothing stops a search engine from referencing it, a user from bookmarking it, etc. So I don't think that's an example of where omitting title is a good idea. Anyone who bookmarks a document that was not meant to be bookmarked should accept the consequences. That doesn't seem like a very user-friendly approach. But it seems that it is pointless to present any situations where it would be legitimate to omit a title element, since you are prepared to refuting any possible example by presenting how things could be different from the scenario given. There are definitely cases where it's ok to not have the title. For example, a srcdoc= document doesn't need a title, since it's not independently addressable. An e-mail has a Subject line so if its body is HTML, it doesn't need a title. Both these examples are in the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] checksum attribute in a href tag
Am 2012-10-19 18:49, schrieb Ian Hickson: What is the attack scenario you are trying to avoid? Without a discussion of what problem you're trying to solve, it's unclear how to evaluate the proposal. The idea of a hash= or checksum= attribute on a href has come up before -- about once a year, as far as I can tell! -- but it's always been found lacking in one way or another. I don't want to avoid any attack scenario! I want trusted information. If I write an article and link to other documents I want a solution that the visitor can be sure that the document he opens is the document I originally linked to. (And if its not he gets informed. So he knows that the information maybe differ from the one the article talks about.) The second point is that verification if a file was downloaded correctly is a computer task not a human task. A standard how to give the verification information enables the browser/plugin vendors to do this task.
Re: [whatwg] checksum attribute in a href tag
On Fri, Oct 19, 2012 at 11:46 AM, A. Rauschenbach rauschenb...@annuo.de wrote: Am 2012-10-19 18:49, schrieb Ian Hickson: What is the attack scenario you are trying to avoid? Without a discussion of what problem you're trying to solve, it's unclear how to evaluate the proposal. The idea of a hash= or checksum= attribute on a href has come up before -- about once a year, as far as I can tell! -- but it's always been found lacking in one way or another. I don't want to avoid any attack scenario! I want trusted information. If I write an article and link to other documents I want a solution that the visitor can be sure that the document he opens is the document I originally linked to. (And if its not he gets informed. So he knows that the information maybe differ from the one the article talks about.) That's also an attach scenario. ^_^ I doubt it would be very useful to use this for confirming that arbitrary destination pages are the same. Those can change in minor, unimportant ways all the time; a lot of pages include some form of dynamic content that means they'll almost *never* be exactly the same from pageload to pageload. It seems highly likely that trying to use a checksum for this scenario would simply result in the browser over-warning people, thus making the warning useless. Using it specifically to defend against attack scenarios in *downloads*, on the other hand, is more likely to be useful. Downloads don't change nearly as much as pages do, so a change is more likely to be a result of something you don't want, rather than simply something incidental. However, check out the threads that Hixie referenced. The upsides and downsides of something like this have been discussed quite a bit already. ~TJ
Re: [whatwg] checksum attribute in a href tag
On Fri, 19 Oct 2012, A. Rauschenbach wrote: If I write an article and link to other documents I want a solution that the visitor can be sure that the document he opens is the document I originally linked to. (And if its not he gets informed. So he knows that the information maybe differ from the one the article talks about.) I don't think this is something that would be very practical. As Tab says, pages change a _lot_. You'd just always be getting a warning that the page had changed, even if the important content had not. The second point is that verification if a file was downloaded correctly is a computer task not a human task. A standard how to give the verification information enables the browser/plugin vendors to do this task. If the file is downloaded over TLS, then it's already verified. Pretty much any attack scenario in which the file can be corrupted (man-in-the-middle, server-side corruption, client-side corruption, etc) can attack the file just as easily as the hash, so there's not really any gain from checking a hash. (This applies equally well to manual checking.) Providing such a feature would, in most cases, just give users a false sense of security. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] checksum attribute in a href tag
A. Rauschenbach rauschenb...@annuo.de schrieb am Fri, 19 Oct 2012 20:46:24 +0200: […] If I write an article and link to other documents I want a solution that the visitor can be sure that the document he opens is the document I originally linked to. Mirror the information. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Character-encoding-related threads
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Fri, 19 Oct 2012 20:49:16 +0300: Anyone who bookmarks a document that was not meant to be bookmarked should accept the consequences. What makes the web – and collaboration between entities in general – tremendously useful is that information can be re-used in novel ways the original authors never thought of. A document that is “not meant to be bookmarked” cannot be markedly different from one that is meant to under these circumstances. Yet you seem to deny, a priori, the possibility that a document does not need a title or a name. Care to elaborate? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
[whatwg] Should scrollbars move focus?
I was working on a bug [1][2] recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) [1] https://bugs.webkit.org/show_bug.cgi?id=96335 [2] http://code.google.com/p/chromium/issues/detail?id=51469 - Elliott
Re: [whatwg] Should scrollbars move focus?
On Fri, 19 Oct 2012, Elliott Sprehn wrote: I was working on a bug recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) From the spec's point of view, I think this is just something where you're supposed to try to match the host platform conventions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should scrollbars move focus?
On Fri, Oct 19, 2012 at 3:34 PM, Elliott Sprehn espr...@gmail.com wrote: I was working on a bug [1][2] recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) [1] https://bugs.webkit.org/show_bug.cgi?id=96335 [2] http://code.google.com/p/chromium/issues/detail?id=51469 I don't have strong opinions, and would be swayed by a decent rationale, but I lean toward making scrollbars never steal focus. It's weird that you can mousewheel or touch scroll without killing your focus, but using the bar steals it. ~TJ
Re: [whatwg] Proposal: new Table Parser Algorithm - new Table API - removal of the headers attribute - removal of the scope attribute
Hi folk,
Proposal: new table Boolean attribute named hassum.
It was bring to my attention of a possible backward compatibility
issue in regards of the interpretation of having multiple subsequent
group in a table.
The issue:
Sometime the subsequent row grouping under the same data level and the
subsequent column grouping under the same data level don't necessary
mean a summary group but still a data group.
The solution:
To fix that the solution would be to have a new attribute set on the
table element to know if the table contains summaries group.
Addition to my initial proposal:
Add new boolean attribute for the table element called hassum for
has summary group. See bellow, from my previous post, the updated
API and Algorithm.
The justification:
This table concept define the relationships between multiple table
groups (tbody, colgroup). The data level calculation stay the same by
default except the data level can be only decreased when the table are
in has summary group mode (new hassum proposed attribute). Having
the support for summary group is important and with that concept it
would be possible to have a better representation of a common used
table like the invoice table.
The possibility to define summary group in a table would allow a
responsive design support for tables. That could result by showing
only the summary group and show, on user request, the associate data
group, intentionally hidden, for a given data level group.
Invoice example with the hassum attribute
table hassum
captionInvoice Table 3/caption
colgroup !-- Header column group --
col /
col /
col /
/colgroup
colgroup !-- Data column group at level 1 --
col /
col /
/colgroup
colgroup !-- Summary column group at level 1 --
col /
/colgroup
thead !-- Header row group --
tr
thProduct ID/th
thProduct/th
thDescription/th
thQuantity/th
thUnit Price/th
thTotal/th
/tr
/thead
tbody !-- Data row group at level 1 --
tr
tdKey/td
thItem/th
tdDescription/td
td2 times/td
td25.99 $/td
td51.98/td
/tr
tr
tdKey/td
thItem/th
tdDescription/td
td2 times/td
td25.99 $/td
td51.98/td
/tr
tr
tdKey/td
thItem/th
tdDescription/td
td2 times/td
td25.99 $/td
td51.98/td
/tr
/tbody
tbody !-- Summary row group at level 1 --
tr
th colspan=5Subtotal/td
td155.94/td
/tr
tr
th colspan=5Taxes (10%)/td
td15.59/td
/tr
/tbody
tbody !-- Summary row group at level 0 --
tr
th colspan=5Total/td
td171.53/td
/tr
/tbody
/table
For different visual rendering if the attribute hassum is present or
not, check http://wet-boew.github.com/wet-boew/demos/zebra/invoice.html
Please see bellow, from my previous email, the revised table API, the
revised Row Group Setup Algorithm and the revised Process Row Group
Headers Algorithm.
On Fri, 28 Sep 2012, Pierre Dubois wrote:
[...]
Proposal: Table Usability API
===
You can find an HTML Version here:
https://github.com/duboisp/Table-Usability-Concept/tree/master/API
## table element
interface HTMLTableElement : HTMLElement {
attribute HTMLTableCaptionElement? caption;
attribute HTMLTableGroupElement?
rowHeaderGroups;
attribute HTMLTableGroupElement? colHeaderGoups;
attribute boolean hassum;
readonly attribute HTMLCollection rowGroups;
readonly attribute HTMLCollection colGroups;
readonly attribute HTMLCollection keys;
readonly attribute HTMLCollection descriptions;
readonly attribute HTMLCollection layouts;
readonly attribute HTMLCollection rows;
readonly attribute HTMLCollection cols;
};
[...]
Proposal: Table Usability Parser Algorithm
===
[...]
## Row Group Setup
* With the header row array
* if the
