Re: [whatwg] Incomplete user-input in some input types
On Thu, Nov 8, 2012 at 7:52 AM, TAMURA, Kent tk...@chromium.org wrote: C. Just validity.valid becomes false. An implementation would have an internal flag like invalidUserInput, but it won't be exposed via IDL. C would have less impact to the standard. If no one has concern about this idea, I'd like to implement C in WebKit. I actually think exposing the UI state makes sense. It's also going to be exposed through a selector: http://dev.w3.org/csswg/selectors4/#user-error-pseudo -- http://annevankesteren.nl/
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Hi all, responses in line On 7 November 2012 19:38, Ian Hickson i...@hixie.ch wrote: On Wed, 7 Nov 2012, Simon Pieters wrote: My impression from TPAC is that implementors are on board with the idea of adding main to HTML, and we're left with Hixie objecting to it. If implementors wish to implement something, my objecting is irrelevant. :-) Just implement it. It appears that some implementers would like Hixie to spec main, but he is unwilling as he disagrees with the feature, In a hallway discussion with a microsoft rep at TPAC he indicated that IE would have no objections to implementing the feature was introduced via the HTML WG, which is what is happening at the moment. I also asked other browser implementers who indicated that agreement from Hixie was not a prerequisite for implementation. I suggest what is a prerequisite is clear use cases and data to back them up and a well defined spec of the feature. These are provided via the main spec and linked documents [1] I have also spoken to various browser accessibility engineers who have agreed that it would be a useful addition to complete the HTML element - ARIA landmark mapping, and that the accessibility part would be trivial to implement [4]: I am generally in favor of a main element, and FWIW, implementation of the semantics should be trivial in WebKit, or any UA that supports the ARIA 'main' landmark role already. another data point: when i discussed the main element with one of the mozilla accessibility engineers they suggested that it would be useful for providing a built in skip to content link, which is one of the use cases. Hixie's argument is, I think, that the use case that main is intended to address is already possible by applying the Scooby-Doo algorithm, as James put it -- remove all elements that are not main content, header, aside, etc., and you're left with the main content. The reason there is no element main in the HTML spec currently is that there are no use cases for it that aren't already handled, right. The use cases data and rationale have been provided [1]. If you have objections it would be useful to respond to them rather than restating your position. I think the Scooby-Doo algorithm is a heuristic that is not reliable enough in practice, since authors are likely to put stuff outside the main content that do not get filtered out by the algorithm, and vice versa. That people will get markup wrong is a given. This will not obviously be any less the case with an element named main than an element named article or elements named nav or aside or header. Agreed that people get markup wrong, I don't agree with your supposition that main would be just as prone to mistakes as the other elements you cited. main is a simple concept, and its use is clearly defined, its limitation of use once per page makes it less prone to mistakes in its use, it is based on concepts that are evident in authoring practises and the evidence of the strong correlation between elements (typically divs) identifying the main content area and their use for role=main and the target of skip links indicates the concept is already understood and in use. In fact, when we have looked at actual data for this (see e.g. the recent thread where I went through Steve's data, or the threads years ago when this first came up), it turns out authors are significantly more reliably using class names that relate to marking up navigation blocks and headers, than they are about marking up main. Authors seem to put class=main and equivalents around every possible combination of content in a page, purely based on their styling needs. Problem is Ian, you haven't responded to the data and use cases, you have have misdirected the discussion by continuing to talk about class names, when the data and use cases and rationale are based on the use of id values. Did the year's old previous discussion take into account id value data or skip link data or role=main placement data? What the relevant new data clearly indicates is that in approx 80% of cases when authors identify the main area of content it is the part of the content that does not include header, footer or navigation content. It also indicates that where skip links are present or role=main is used their position correlates highly with the use of id values designating the main content area of a page. furthermore when ARIA role=main is used in 95% [3] of the cases in the data sampled it is used once only which is a clear indicator that authors get how to identify the main content area of a page. * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample [2]) * There is a strong correlation between use of role='main' on an element with id values of 'content' or 'main' or permutations. (when used = 101 pages) 77%
Re: [whatwg] Sortable Tables
On Wed, Nov 7, 2012 at 11:42 AM, Simon Pieters sim...@opera.com wrote: On Wed, 07 Nov 2012 10:54:19 +0100, Jirka Kosek ji...@kosek.cz wrote: On 6.11.2012 23:18, Silvia Pfeiffer wrote: * data-type: date, number, text etc which determines the comparison function used in sort It would be very difficult to support sorting on dates and numbers as in HTML they are usually present formatted using specific locale. So there should be additional attribute added to td/th which can hold sort key which will override cell contents, something like td sortas=2012-11-0711. listopadu 2012/td time exists, and data exists for non-time machine-readable data; maybe they can be utilized in some way? I have done some investigation in this area too and having concrete datatypes would make this more utilizable, ie from the proposal for data type= value=/ http://www.w3.org/wiki/User:Cjones/ISSUE-184 The other area of integration would be with BCP-47 language tags and the CLDR which include i18n collation information, for example british numeric collation: en-GB-*u-kn-true* The significant benefit with this is that this standard is already universal across server\client and is of course fully internationalized. The other aspect of this is that there is a distinction between server pagination including sort ordering defining the content of a page and the client-based sorting which would be more of a presentational customization and outside the scope of pagination. As such, it may be better for the HTML to markup the structure of the content with sorting and collation but for this to be configurable through CSS without the structural DOM changes. This could also apply to HTML lists: ul ol, dl. Thanks, Cameron Jones
Re: [whatwg] Sortable Tables
I'm much more inclined to solve this from the data axis. Asking the table itself to do the sorting is weird. Instead, you most often want to have some data source return you rows in sorted order (or indicate row order). If you do something like MDV, sorting the table is applying a sort to the template that stamped out the view. That works with DOM-table backed tables as well as server or JS-backed tables. On Tue, Nov 6, 2012 at 7:39 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph Päper wrote: It's a common task outside HTML to sort tables by one or more of its columns. There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. http://meta.wikimedia.org/wiki/Help:Sorting, http://tablesorter.com/docs/. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary. For starters, only rows inside ‘tbody’s shall be reordered. For now columns don’t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ‘col’ and ‘colgroup’ elements are hardly supported. Not every column has content that makes sense to be sorted in a different order. So non-sortable columns inside sortable tables should be marked as such. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Several columns may be used for sorting by some kind of priority. The original order must be restorable. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional attribute indicating their sort key. The ‘time’ element already provides the necessary metadata features for temporal sorting – maybe there should be more of such elements instead. There may be columns that shall remain stable, eg. rank numbers. This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. This is a use-case that I absolutely think it makes sense to address. This is extremely common whenever people use tables for actual tabular data and it's non-trivial to do in a way that performs well. I'd have to see a more concrete proposal in order to evaluate whether I'd be interested in implementing it. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those.
[whatwg] [URL] DOM API Feedback
Howdy all, Anne asked me to send feedback on the DOM API for the new URL spec ( http://url.spec.whatwg.org/#api) to this list. Here goes: First, I love that this looks sane, like what you need most of the time, and will plumb through to the browser's parsing algorithm without requiring me to re-write this sort of thing (badly) every time I need it. +1 for adding a good DOM API! Next, nicely done on having a meaningful constructor! I do wonder if the url parameter should be optional as well as the base, since you may either want to build a URL using a URL object (to be serialized later). Looking at what URL/URLUtils provides, I noted a couple of things I'd like to see that I miss from google-urlhttp://code.google.com/p/google-url/source/browse/trunk/src/gurl.h(a.k.a. GURL, the URL library we use in Chrome): - GetWithEmptyPath() GetOrigin() (despite their terrible C++ naming) are hugely useful for doing comparisons. I could imagine that there's some - username and password properties are missing - There aren't any provided comparison functions. I.e., there's no way to tell if two URL objects reference the same absolute URL, if one references a path in the same domain, etc. - Is there any attempt to parse query parameters and/or return a form data object from them? Also, what's the default base URL? If I'm in a document with a base set, are instances that don't specify one relative to the origin of the window object from which the instance is created? I ask, because in the caes of: new URL(/thinger.html); I'd expect identical calls like that to have different toString() values if executed on foo.com and bar.com. It was unclear to me if that's the case today. Anyhow, I like this. Nice work!
Re: [whatwg] Sortable Tables
Ian Hickson:
On Thu, 1 Jul 2010, Christoph Päper wrote:
Darn, my reply from yesterday got lost in data nirvana. This is a slightly
shorter version thereof.
So sortable tables should be marked as such.
Opt-in:
table sortable collapsible
“sortable=auto” should be the default and resolve to ‘sortable’ if at least one
column has a sort key assigned, and to ‘fixed’ (or the like) otherwise.
(Row and column collapsing is a related, but different beast. Let’s deal with
that separately, later.)
Note that ‘col’ and ‘colgroup’ elements are hardly supported.
Nevertheless, it’s usually sufficient to mark one column as containing values
to use as sort key.
colgroup key=…
col key=…
Columns inherit the key from their group, but may override it.
non-sortable columns inside sortable tables should be marked as such.
key=none
Not to be confused with fixed columns.
There are different ways to sort, eg. numeric, temporal or alphabetic
key=numeric 1 2 10
key=alpha Ä = ä = A#x0308; (= a?), 1 10 2
key=date2012-11-08 = 2012-W45-4
key=value 1000 g = 1 kg = 0.001 t 1 lb
key=style although Excel can do this to some degree, it’s hardly useful
key=class slightly more useful
key=id ditto
and ascending or descending.
That’s better left to the UI: switch order when sorting for the second time.
Several columns may be used for sorting by some kind of priority.
Also primarily a UI question: use previously sorted column as secondary key.
key=1 primary key for heuristic sorting algorithm
The original order must be restorable.
UI again, e.g. tristate column sort: ascending, descending, original, …
Cells should have an optional attribute indicating their sort key.
td value=0.4541 lb
There may be columns that shall remain stable, eg. rank numbers.
key=fixed
The sorting algorithm should not work on cells, but on slots (or slot values
rather).
Cells spanning multiple rows or columns may have to be split into one cell per
slot and should be rejoined afterwards if possible. Note that ‘rowspan’ itself
is safe for vertical sorting, unless it spans a ‘fixed’ column. Also, ‘colspan‘
is safe when it appears in the column to be sorted by.
td {color: green}
[rowspan] {color: red}
trtd1 td rowspan=2red 1 red
trtd3 =sort=col1= 2 green
trtd2 tdgreen 3 red
The text reads its color! A cell at (1,1) – counting starts from 0 – never
exists, the slot at the same position changes its value from ‘red’ to ‘green’.
Re: [whatwg] Sortable Tables
I like this approach. One thing this loses is having default styling for sortable headers. It would be awesome if sortable tables looked the same across pages instead of each page needing to invent their own up/down arrow UI. Also, is MDV intelligent enough to know that you just moved items around or will it clobber and recreate the entire DOM? On Thu, Nov 8, 2012 at 4:17 AM, Alex Russell slightly...@google.com wrote: I'm much more inclined to solve this from the data axis. Asking the table itself to do the sorting is weird. Instead, you most often want to have some data source return you rows in sorted order (or indicate row order). If you do something like MDV, sorting the table is applying a sort to the template that stamped out the view. That works with DOM-table backed tables as well as server or JS-backed tables. On Tue, Nov 6, 2012 at 7:39 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph Päper wrote: It's a common task outside HTML to sort tables by one or more of its columns. There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. http://meta.wikimedia.org/wiki/Help:Sorting, http://tablesorter.com/docs/. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary. For starters, only rows inside ‘tbody’s shall be reordered. For now columns don’t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ‘col’ and ‘colgroup’ elements are hardly supported. Not every column has content that makes sense to be sorted in a different order. So non-sortable columns inside sortable tables should be marked as such. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Several columns may be used for sorting by some kind of priority. The original order must be restorable. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional attribute indicating their sort key. The ‘time’ element already provides the necessary metadata features for temporal sorting – maybe there should be more of such elements instead. There may be columns that shall remain stable, eg. rank numbers. This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. This is a use-case that I absolutely think it makes sense to address. This is extremely common whenever people use tables for actual tabular data and it's non-trivial to do in a way that performs well. I'd have to see a more concrete proposal in order to evaluate whether I'd be interested in implementing it. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those.
Re: [whatwg] Sortable Tables
On Thu, Nov 8, 2012 at 8:59 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Nov 8, 2012 at 4:17 AM, Alex Russell slightly...@google.com wrote: I'm much more inclined to solve this from the data axis. Asking the table itself to do the sorting is weird. Instead, you most often want to have some data source return you rows in sorted order (or indicate row order). If you do something like MDV, sorting the table is applying a sort to the template that stamped out the view. That works with DOM-table backed tables as well as server or JS-backed tables. I like this approach. One thing this loses is having default styling for sortable headers. It would be awesome if sortable tables looked the same across pages instead of each page needing to invent their own up/down arrow UI. Agreed, I favor a DOM-based solution because of this. Also, is MDV intelligent enough to know that you just moved items around or will it clobber and recreate the entire DOM? It *should* be intelligent enough to recognize moves, as opposed to just add/deletes. Ask Raf or Adam about their progress on getting this done. ~TJ
[whatwg] Location object identity and navigation behavior
The current spec for the Location object doesn't match reality. At the moment, the spec says that Location is a per-Window object that describes the associated Document. However, in our testing, it appears that none of the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all implementations of Location describe the active document in the browsing context (that is to say, the referent of the WindowProxy). This suggests that the spec's current language is likely not web-compatible. If the Location object describes the browsing context, we're left to consider whether there should be one Location object per Window or one Location object per browsing context. Gecko and Webkit currently do the former, and Trident and Presto do the latter (see again [1]). I would like to change Gecko's behavior here [2], because would simplify a lot of security invariants and generally make things more sane. How do WebKit folks feel about this? If Location follows the WindowProxy, an interesting question is what happens to expando properties on navigation. I did some testing, and UAs seem to have pretty inconsistent behavior here [3]. As such, I think the sanest policy is simply to clear expandos on Location each time the page is navigated. This is the approach I've taken in the patches in [2]. Thoughts? Cheers, bholley [1] http://people.mozilla.org/~mwobensmith/window_test/doc_win.htm [2] https://bugzilla.mozilla.org/show_bug.cgi?id=808608 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=808608#c8
Re: [whatwg] [URL] DOM API Feedback
On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell slightly...@google.com wrote: Howdy all, Anne asked me to send feedback on the DOM API for the new URL spec ( http://url.spec.whatwg.org/#api) to this list. Here goes: First, I love that this looks sane, like what you need most of the time, and will plumb through to the browser's parsing algorithm without requiring me to re-write this sort of thing (badly) every time I need it. +1 for adding a good DOM API! Next, nicely done on having a meaningful constructor! I do wonder if the url parameter should be optional as well as the base, since you may either want to build a URL using a URL object (to be serialized later). Looking at what URL/URLUtils provides, I noted a couple of things I'd like to see that I miss from google-urlhttp://code.google.com/p/google-url/source/browse/trunk/src/gurl.h(a.k.a. GURL, the URL library we use in Chrome): - GetWithEmptyPath() GetOrigin() (despite their terrible C++ naming) are hugely useful for doing comparisons. I could imagine that there's some http://url.spec.whatwg.org/#dom-url-origin is the equivalent to GURL's GetOrigin(). - username and password properties are missing - There aren't any provided comparison functions. I.e., there's no way to tell if two URL objects reference the same absolute URL, if one references a path in the same domain, etc. The notion of the same absolute URL is a bit slippery. It depends on how well you understand various URL components (e.g., octal encodings of IP addesss). We could define something, of course, but we'd just need to do so carefully. - Is there any attempt to parse query parameters and/or return a form data object from them? Yes, the http://url.spec.whatwg.org/#urlquery interface lets you get at parsed URL parameters. I don't think there's currently a way to turn them into form data objects, but that would make sense. We might also want to add a bulk setter that takes a Dictionary. Also, what's the default base URL? If I'm in a document with a base set, are instances that don't specify one relative to the origin of the window object from which the instance is created? I ask, because in the caes of: new URL(/thinger.html); I'd expect identical calls like that to have different toString() values if executed on foo.com and bar.com. It was unclear to me if that's the case today. That's covered in step 1 of http://url.spec.whatwg.org/#constructors. If there's no explicit base, the URL is resolved relative to about:blank. To me, that seems better that implicitly using the document's base URL. You can always supply the document's base URL from document.baseURI if you want. Adam
Re: [whatwg] Location object identity and navigation behavior
On Thu, Nov 8, 2012 at 10:19 AM, Bobby Holley bobbyhol...@gmail.com wrote:
The current spec for the Location object doesn't match reality. At the
moment, the spec says that Location is a per-Window object that describes
the associated Document. However, in our testing, it appears that none of
the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all
implementations of Location describe the active document in the browsing
context (that is to say, the referent of the WindowProxy). This suggests
that the spec's current language is likely not web-compatible.
If the Location object describes the browsing context, we're left to
consider whether there should be one Location object per Window or one
Location object per browsing context. Gecko and Webkit currently do the
former, and Trident and Presto do the latter (see again [1]). I would like
to change Gecko's behavior here [2], because would simplify a lot of
security invariants and generally make things more sane. How do WebKit
folks feel about this?
I'm not sure I quite understand what you mean here. Can you describe
an experiment that would distinguish these cases? I looked at [1],
but it was too complicated for me to understand quickly.
Consider the following case:
== Document A ==
script
Object.prototype.foo = A1;
window.location.bar = A2;
function f() {
var loc = window.location;
print(loc.foo); // print is a magic function that lets me see this value
print(loc.bar);
}
/script
== Document B ==
script
Object.prototype.foo = B1;
window.location.bar = B2;
/script
1) Document A is displayed in browsing context X.
2) Browsing context X is navigated and now displays document B.
3) Function f is called.
What values are printed?
If Location follows the WindowProxy, an interesting question is what
happens to expando properties on navigation. I did some testing, and UAs
seem to have pretty inconsistent behavior here [3]. As such, I think the
sanest policy is simply to clear expandos on Location each time the page is
navigated. This is the approach I've taken in the patches in [2].
I don't think I quite understand what you mean, but the way this works
in WebKit is that each Window object has its own Location object. The
location object operates on the current Window for the WindowProxy.
In WebKit at least, it would be a security vulnerability to expose
JavaScript objects that belong to Document B to Document A because
that would give Document A access to the prototype objects for
Document B.
Adam
Re: [whatwg] Location object identity and navigation behavior
On 11/8/12 6:09 PM, Adam Barth wrote: I don't think I quite understand what you mean, but the way this works in WebKit is that each Window object has its own Location object. That's not how it works in Presto and Trident, as far as we can tell based on testing with ==. In those, each WindowProxy has its own Location object. The location object operates on the current Window for the WindowProxy. Yes. _That_ all browsers are consistent on, and is totally not what the spec says right now. In the spec, there is one Location per Window, and the object operates on the Window it's associated with. The fact that this does not match any browsers is what makes us suspect the spec is not web-compatible. In WebKit at least, it would be a security vulnerability to expose JavaScript objects that belong to Document B to Document A because that would give Document A access to the prototype objects for Document B. You presumably have a solution for this situation for the WindowProxy case, right? Certainly Gecko does, and we would be using the same solution for Location if we tie the lifetime of a Location to the lifetime of a WindowProxy. -Boris P.S. I'll leave it to Matt and Bobby to answer your question about your testcase with function f(), because while I suspect I know what UAs do there in practice there is no way to tell without actually testing...
