Re: [whatwg] Sortable Tables
On Wed, Nov 7, 2012 at 8:37 PM, 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 Agreed. My example was very crude and simple and worked fine for our purposes, but something more generic (and internationalized) needs more functionality like this. Silvia.
Re: [whatwg] Sortable Tables
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 Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
[whatwg] main element parsing behaviour
Hi all, After discussions with various implementers there appears to be some questions about the main element and the parsing algorithm Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec [1] to define parsing for the element? also any other feedback welcome. https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- 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] main element parsing behaviour
On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec to define parsing for the element? What did you do with the feedback you already got on this front? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html -- http://annevankesteren.nl/
Re: [whatwg] Sortable Tables
I'm the author of http://www.kryogenix.org/code/browser/sorttable/, a
moderately popular JavaScript table sorting script. As such, I have about
nine years worth of anecdata about how authors want their HTML tables to be
sorted, the sorts of things they request, and issues that may be worth
taking into consideration. These are not particularly in order; they're
just things that I think are relevant.
Sorttable.js, my script, has the guiding principle of not needing
configuration in most cases. Therefore, it attempts to guess the type of a
table column: if a column looks like it contains numbers, sorttable will
use numeric sort (1 before 2 before 100) rather than alphanumeric sort (1
before 100 before 2); if a column looks like it contains date information,
then sorttable will sort by date (for formats DD/MM/ and MM/DD/).
The algorithm used for this guessing is pretty naive (check the first cell
in a column; if it's blank, check the next one; etc). I think that this, by
itself, has accounted for sorttable's popularity, because in most cases, it
Just Works; you add a script element pointing to the script, and
class=sortable to the table, and do *nothing else*, and your table is
sortable without any configuration.
Everything else below here is configuration-based: something you'd have to
do explicitly as an author. The above point is the critical one; guessing
column types to make table sorting be zero-config. Some alternative scripts
require you to explicitly tag date or numeric columns, and I think that
authors see that as annoying. Anecdata, of course.
Sorttable also allows authors to specify alternate content for a cell.
That is (ignore the invalid HTML attribute here; I didn't know any better,
and we didn't have data-* attributes when I wrote this stuff)
td sorttable_customkey=11eleven/td
This is basically useful for when you have table data which has a definite
order but it can't be autoguessed, or (more usefully still) when it could
be autoguessed but that would be hard. The canonical example of this is
dates: it would be exceedingly annoying, given
tdWed 7th November, 10.00am GMT/td
to have to parse that cell content in JavaScript to turn it back into a
Date() so it can be placed in sort order with other dates. The sorttable.js
solution is to specify a custom key, which sorttable pretends was the
cell content for the purposes of sorting, so
td sorttable_customkey=20121107-10Wed 7th November, 10.00am GMT/td
and then the script can sort it. This feature is basically the get-out
clause, an author hook for saying I know what I want, but your fancy
sorting thing can't handle it; how do I override that? They can specify
custom keys for all their TDs and then sorting will work fine. (Obviously,
dates are less of a problem in theory today with date elements, but...
how does the script know to use the datetime attribute of the date in
tddate.../date/td?)
In roughly descending order of popularity, here is what I've been asked
questions about, over the last decade or so:
1. Sorting tables inserted after page load. This is obviously not a problem
(sorting a table created with JS rather than in the base HTML), and
sorttable should handle it without explicit action from the author to
mark a table as sortable, but it doesn't because of laziness from me. I
include it for completeness because sorttable not handling it generates
probably a third of all the sorttable complaint email I receive; a properly
specced sortable tables implementation in browsers would obviously handle
this and wouldn't need to even have it specified.
2. Sorting a table on page load. That is: a table in HTML containing
unsorted data should be sorted by the browser when the page loads, without
user action. Sorttable doesn't do this because I think it's wrong (if you
want sorted data when the page loads, serve it as sorted in the HTML), but
lots of people ask for it.
3. Multiple header rows. Many authors have two or more trs in the
thead, one of which contains rowspanned ths, to group columns together.
If this happens, which ths are clickable to sort the table? Which are
not? This is hard to autodiagnose (and indeed sorttable punts on it and
picks the first one, which is almost certainly wrong; even naively picking
the last tr inside thead would be better, but still imperfect).
4. Handling colspans and rowspans in the table. Sorttable.js basically
punts on this, because what's expected to happen when you sort a column
which contains only half a cell (because the other half's in another
column, with rowspan=2) is wildly author-specific. But a properly specced
solution doesn't get to punt and say unsupported. This will need some
thought.
5. Numeric sort handling exponented numbers such as 1.5e6 (which do not
match a naive is this a number regexp such as /^[0-9]+$/ )
6. Specifying how to display that a column is sorted. This would likely be
done in this specification by leaving it to CSS and th::sorted-forward {
after: content(v
Re: [whatwg] main element parsing behaviour
Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? regards SteveF On 7 November 2012 10:30, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec to define parsing for the element? What did you do with the feedback you already got on this front? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html -- http://annevankesteren.nl/ -- 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] Sortable Tables
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? -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? That's right. I'm not convinced that we should freeze the parser now just because we have reached interop. I think not changing the parser here makes main (and other future elements; whatever we do here sets a precedent for future elements) inconsistent with the rest of HTML. In the long term, having main and aside parse differently just because we didn't want to change the behavior from 2012-era browsers will seem silly. Moreover, it will complicate the already complicated rules about when /p may be omitted (in terms of how people think of the rule), which means that we might have to say that /p is always required. I'm also not convinced by Henri's assertion that p will not precede main in conforming content. p is used for all sorts of things, not just a paragraph of text. -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 12:46:36 +0100, Simon Pieters sim...@opera.com wrote: On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? That's right. OTOH, if we wanted main to parse like aside, we'd add main to: [[ A start tag whose tag name is one of: address, article, aside, blockquote, center, details, dialog, dir, div, dl, fieldset, figcaption, figure, footer, header, hgroup, menu, nav, ol, p, section, summary, ul ]] and: [[ An end tag whose tag name is one of: address, article, aside, blockquote, button, center, details, dialog, dir, div, dl, fieldset, figcaption, figure, footer, header, hgroup, listing, menu, nav, ol, pre, section, summary, ul ]] in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On 7.11.2012 12:46, Simon Pieters wrote: I'm not convinced that we should freeze the parser now just because we have reached interop. I think not changing the parser here makes main (and other future elements; whatever we do here sets a precedent for future elements) inconsistent with the rest of HTML. In the long term, having main and aside parse differently just because we didn't want to change the behavior from 2012-era browsers will seem silly. Moreover, it will complicate the already complicated rules about when /p may be omitted (in terms of how people think of the rule), which means that we might have to say that /p is always required. Changing parser each time new element is added is really evil idea and sign of a bad design. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On Wed, Nov 7, 2012 at 12:55 PM, Jirka Kosek ji...@kosek.cz wrote: Changing parser each time new element is added is really evil idea and sign of a bad design. HTML badly designed? Film at 11. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. The problem is that the treatment of an element is largely a function of its purpose. -- http://annevankesteren.nl/
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 12:55:46 +0100, Jirka Kosek ji...@kosek.cz wrote: Changing parser each time new element is added is really evil idea and sign of a bad design. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. There are three ways to parse a new element that we probably want for new elements: inline - like span, current behavior for unknown elements. block - like address, currently a finite list of elements. void - like img, currently a finite list of elements. (Possibly also block void, - like hr, although none such elements have been added since parsing was specified.) If we were to design a system where we can make up new elements that go in one of those categories without changing the parser, I think we effectively have to put a magic string in the tag name, e.g. any element that starts with block is treated like address, but that has disadvantages: * Looking at a substring of the tag name complicates the parser and probably ruins some optimizations. * It means new non-inline elements will have long, ugly two-word names which is inconsistent with the rest of the language. I can imagine other designs as well but they don't seem any better. In conclusion, I think changing the parser when we introduce a new block or void element is a better approach. -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On 7.11.2012 13:13, Simon Pieters wrote: If we were to design a system where we can make up new elements that go in one of those categories without changing the parser, I think we effectively have to put a magic string in the tag name, e.g. any element that starts with block is treated like address, but that has disadvantages: * Looking at a substring of the tag name complicates the parser and probably ruins some optimizations. * It means new non-inline elements will have long, ugly two-word names which is inconsistent with the rest of the language. Indeed, this doesn't seem very appealing. I can imagine other designs as well but they don't seem any better. In conclusion, I think changing the parser when we introduce a new block or void element is a better approach. I think it's better to treat all new elements as inline (from parsing point of view) then to change algorithm each time. Changing parsing each time also means that such changes can't be undone. Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 13:25:14 +0100, Jirka Kosek ji...@kosek.cz wrote: Changing parsing each time also means that such changes can't be undone. They can be undone if doing so doesn't break the Web. Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. -- Simon Pieters Opera Software
Re: [whatwg] main element parsing behaviour
On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters sim...@opera.com wrote: I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference between the parsing algorithm on the UA stylesheet is that authors can put display: block; in the author stylesheet during the transition. That said, the example jgraham showed to me on IRC convinced me that if main is introduced to the platform, it makes sense to make it parse like article. :-( (I’m not a fan of the consequences of the “feature” of making /p optional. Too bad that feature is ancient and it’s too late on undo it.) I guess I’ll focus on objecting to new void elements and especially to new children of head. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] main element parsing behaviour
On 7.11.2012 13:42, Simon Pieters wrote: Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference is that deficiency of parsing algorithm can't be compensated by JS or CSS. Until new element is widely supported you can define it's styling in your CSS file or link to Javascript shim which will provide functionality in older browsers. But I don't think that you can alter parsing algorithm in the similar way. Web browsers are now upgraded much more frequently and regularly so change to PA might look like non problem. But various non-browser applications are relying on HTML5 parsing libraries and those will not be regularly updated. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On Wed, 07 Nov 2012 13:47:53 +0100, Henri Sivonen hsivo...@iki.fi wrote: On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters sim...@opera.com wrote: I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference between the parsing algorithm on the UA stylesheet is that authors can put display: block; in the author stylesheet during the transition. I guess that's fair. That said, the example jgraham showed to me on IRC convinced me that if main is introduced to the platform, it makes sense to make it parse like article. :-( (I’m not a fan of the consequences of the “feature” of making /p optional. Too bad that feature is ancient and it’s too late on undo it.) For the record, the example is: mainp/mainp (The last p can be anything.) I guess I’ll focus on objecting to new void elements and especially to new children of head. -- Simon Pieters Opera Software
[whatwg] main UA style sheet
Hi
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
says
[[
The User Agent style sheet should include the following style rule for the
main element:
main {
display:block;
}
]]
I think this is a bit inconsistent with the HTML spec.
First, it should be clear that this should hook in to the HTML spec's
Rendering section, because this section has special rules when it comes to
conformance classes and the use of words with requirements, as explained
at the start of the section.
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#rendering
This section also has this requirement:
[[
The CSS rules given in these subsections are, except where otherwise
specified, expected to be used as part of the user-agent level style sheet
defaults for all documents that contain HTML elements.
]]
I propose the following concrete text:
[[
=== Rendering ===
This section is to be treated as a subsection of HTML's Rendering section
for the purpose of terminology, conformance classes and requirements.
[HTML]
CSS:
... the style sheet ...
]]
Finally, I think the style sheet needs some tweaks. If we want main to
have the same styles as aside (except for the effect aside has on
h1, since main is not a sectioning element), I think the style sheet
should be:
@namespace url(http://www.w3.org/1999/xhtml);
main { unicode-bidi: isolate; display: block; }
Replace this rule in the HTML spec:
:matches([dir=ltr i], [dir=rtl i], [dir=auto
i]):not(address):not(blockquote
):not(center):not(div):not(figure):not(figcaption):not(footer):not(form
):not(header):not(hr):not(legend):not(listing):not(p):not(plaintext):not(pre
):not(summary):not(xmp):not(article):not(aside):not(h1):not(h2):not(h3):not(h4
):not(h5):not(h6):not(hgroup):not(nav):not(section):not(table):not(caption
):not(colgroup):not(col):not(thead):not(tbody):not(tfoot):not(tr):not(td
):not(th):not(dir):not(dd):not(dl):not(dt):not(menu):not(ol):not(ul):not(li)
{
unicode-bidi: embed;
}
with:
:matches([dir=ltr i], [dir=rtl i], [dir=auto
i]):not(address):not(blockquote
):not(center):not(div):not(figure):not(figcaption):not(footer):not(form
):not(header):not(hr):not(legend):not(listing):not(p):not(plaintext):not(pre
):not(summary):not(xmp):not(article):not(aside):not(main):not(h1):not(h2):not(h3):not(h4
):not(h5):not(h6):not(hgroup):not(nav):not(section):not(table):not(caption
):not(colgroup):not(col):not(thead):not(tbody):not(tfoot):not(tr):not(td
):not(th):not(dir):not(dd):not(dl):not(dt):not(menu):not(ol):not(ul):not(li)
{
unicode-bidi: embed;
}
--
Simon Pieters
Opera Software
[whatwg] A plea to Hixie to adopt main
Hi, 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. 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. 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. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. -- Simon Pieters Opera Software
Re: [whatwg] A plea to Hixie to adopt main
I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? contentinfo banner ? What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for? On 08/11/2012, at 1:23 AM, Simon Pieters sim...@opera.com wrote: Hi, 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. 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. 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. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. -- Simon Pieters Opera Software
Re: [whatwg] A plea to Hixie to adopt main
2012-11-07 16:23, Simon Pieters wrote: 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. Hixie's idea is sufficient for determining the main content (in some sense) on a page that systematically uses the new structuring elements. This in turn is sufficient for some styling purposes, but not all purposes. 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's one point. Another point is that authors don't really need to use all the header, nav, etc. elements, and validation does not check for this. E.g., if you just want to have some styles that only apply to the main content, you might want to use just main and not all the other stuff. But perhaps the strongest argument in favor of main is that the Scooby-Doo algorithm may determine the content, but it does not make it an element, on any DOM node. And elementhood is essential for many styling and scripting purposes. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. Sounds logical. And the Reader Mode functionality that you mention is one of the few signs of any meaningful support to the new structuring elements. There is much talk about the assumed semantic benefits of those elements, much less evidence of real benefits. I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. Then again, a similar argument would apply to header and friends. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. Well, I haven't seen much point in any of the new structuring elements in general, but the browser behavior you write about would make main much more relevant than the others. Yucca
Re: [whatwg] A plea to Hixie to adopt main
Hi Ben, I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? contentinfo banner ? What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for? various new HTML elements are already being mapped to ARIA or platform accessibility APIs aside is mapped to complementary ( IA2, AT-SPI and AX) article is mapped to article ( IA2, AT-SPI and AX) nav is mapped to navigation ( IA2, AT-SPI and AX) header/footer are mapped to banner and conteninfo ( IA2, AT-SPI and AX) etc. this means when fuly implemented authors will not have to add aria roles (built in vs bolt-on) the browsers do it already. ARIA roles are used because the semantics are not fully implemented in browsers yet. If you take the time to read the spec [1] and supporting research you will find the rationale and use cases detailed. Its based on commont authoring practice. [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html regards SteveF On 08/11/2012, at 1:23 AM, Simon Pieters sim...@opera.com wrote: Hi, 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. 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. 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. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. -- Simon Pieters Opera Software -- 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] A plea to Hixie to adopt main
On Wed, 07 Nov 2012 15:35:31 +0100, Ben Schwarz ben.schw...@gmail.com wrote: I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo There is an implicit mapping already. and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? It ends at main since that's the last landmark lacking an element. contentinfo banner ? The are called footer and header. What is to be gained by adding an element, rather than using ARIA roles? The gain is better ergonomics and more likelihood of getting accessible pages by people using the elements without doing extra work to cater for AT. Isn't that what ARIA is designed for? The role and state part of ARIA was designed to be a stop-gap solution to make JS-based Web applications accessible in a way that would work in legacy IE with modern AT. The landmark part of ARIA was designed to do the same thing as the new elements in HTML. IIRC, landmarks were kept instead of embracing the new elements because the elements were specified in a document that was not expected to be finished in two decades whereas ARIA was expected to be finished in a much shorter time frame. That we would end up having both was not seen as a showstopper for either group. -- Simon Pieters Opera Software
Re: [whatwg] A plea to Hixie to adopt main
2012-11-07 16:53, Steve Faulkner wrote: ARIA roles are used because the semantics are not fully implemented in browsers yet. It's a bit more complicated than that, isn't it? ARIA roles are also, and originally, meant for describing the meaning of elements that are used in rich Internet applications in a manner that cannot be deduced from the HTML markup. For example, if you set up a span element that acts as a checkbox, driven by JavaScript and formatted with CSS to look like a checkbox, then the ARIA role attribute is needed to inform browsers and assistive software about this. Besides, many distinctions that can be made with ARIA roles cannot be described in HTML as currently defined. But that's not a big issue really, and it does not mean that corresponding elements should be added to HTML. ARIA has its role (no pun intended), and software that can currently handle role=foo would really benefit nothing from the introduction of a foo element. It would be just some new stuff that should be supported in addition to existing support. So the existence of something as an ARIA role value does not imply that a correspoding element should be added to HTML if not already present there. But neither does it constitute a counterargument to adding new elements. Yucca
Re: [whatwg] A plea to Hixie to adopt main
Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names.
Re: [whatwg] A plea to Hixie to adopt main
On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com 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. For those of use who couldn't make it, which browser vendors voiced support? I assume Opera since you're writing this thread. 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. 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. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. This idea doesn't seem to address any pressing use-cases. I don't expect authors to use it as intended consistently enough for it to be useful in practice for things like Safari's Reader mode. You're stuck needing to use something like the Scooby-Doo algorithm most of the time anyways. I don't outright object, but I think our time would be better spent on addressing more pressing problems with the web platform.
Re: [whatwg] A plea to Hixie to adopt main
On 11/07/2012 05:52 PM, Ojan Vafai wrote: On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com 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. For those of use who couldn't make it, which browser vendors voiced support? I assume Opera since you're writing this thread. To be clear, Opera didn't voice support for anything. Some people from Opera suggested that it seemed like a reasonable idea (I think it seems like a reasonable idea). 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. 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. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. This idea doesn't seem to address any pressing use-cases. I think that finding the main content of a page has clear use cases. We can see examples of authors working around the lack of this feature in the platform every time they use a skip to main link, or (less commonly) aria role=main. I believe we also see browsers supporting role=main in their AT mapping, which suggests implementer interest in this approach since the solutions are functionally isomorphic (but with very different marketing and usability stories). I think the argument that the Scooby Doo algorithm is deficient because it requires many elements of a page to be correctly marked up, compared to main which requires only a single element to get the same functional effect, has merit. The observation that having one element on a page marked — via class or id — main is already a clear cowpath enhances the credibility of the suggested solution. On the other hand, I agree that now everyone heading down the cowpath was aiming for the same place; a div class=main wrapping the whole page, headers, footers, and all is clearly not the same as one that identifies the extent of the primary content. I don't know how these different uses stack up (apologies if it is in some research that I overlooked). I don't expect authors to use it as intended consistently enough for it to be useful in practice for things like Safari's Reader mode. You're stuck needing to use something like the Scooby-Doo algorithm most of the time anyways. I think Maciej commented on this. IIRC, he said that it wouldn't be good enough for reader mode alone, but might usefully provide an extra piece of data for the heuristics. I don't outright object, but I think our time would be better spent on addressing more pressing problems with the web platform. I think that's a very weak argument. In fact, given the current landscape I would expect this to swallow more of the web standards communities' time if it is not adopted than if it is. But I don't think that's a strong argument in favour of adopting it either.
Re: [whatwg] A plea to Hixie to adopt main
(12/11/08 1:48), James Graham wrote: I think that finding the main content of a page has clear use cases. We can see examples of authors working around the lack of this feature in the platform every time they use a skip to main link, or (less commonly) aria role=main. I believe we also see browsers supporting role=main in their AT mapping, which suggests implementer interest in this approach since the solutions are functionally isomorphic (but with very different marketing and usability stories). I think the argument that the Scooby Doo algorithm is deficient because it requires many elements of a page to be correctly marked up, compared to main which requires only a single element to get the same functional effect, has merit. Hixie's another argument, if I understand correctly, is to use article in place of this role. I think the Web is probably full of mis-used article already such that using the first article in document order has no chance to work out, but it would nice if this can be verified, even though I can already imagine that an author is unlikely to mark up the main content with article when the main content isn't an article in English sense. The observation that having one element on a page marked — via class or id — main is already a clear cowpath enhances the credibility of the suggested solution. On the other hand, I agree that now everyone heading down the cowpath was aiming for the same place; a div class=main wrapping the whole page, headers, footers, and all is clearly not the same as one that identifies the extent of the primary content. Right. So, assuming skip to main is the only use case for main, which I am not sure if Steve agrees, I think the proposal should use strong wording to prevent such misuse and the proposal should include one example of such misuse and explains it. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A plea to Hixie to adopt main
As a developer I'm in favor of this. Just take a look at the how popular the question of How do I enable Reader mode is on SO[1], and how complex and mysterious the actual algorithm appears to be[2], and it's evident how authors and implementors alike could benefit from a dedicated element. Although, there's the question of how similar in definition it'd be to article. Is it merely a more specific version of a self-contained composition [...] that is, in principle, independently distributable? Or is it a more specific div; a semantic wrapper element? If it's the former, this could just as well be an empty attribute, as article main. Not too different from ARIA, which maybe makes it a little redundant, but it's less to type in CSS (article[main] vs article[role=main]), and also achieves landmark parity without breaking legacy HTML parsers, frameworks, etc. which only expect article. If it's the latter, it probably makes more sense for it to be an element, where it wouldn't say whether the content was self-contained or not; just that its contents are considered the primary focus of the page, except anything that would otherwise be excluded in the document outline. [1]: http://stackoverflow.com/questions/2997918/how-to-enable-ios-5-safari-reader-on-my-website [2]: http://mathiasbynens.be/notes/safari-reader
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
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. 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. 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. 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. Thus if the use case is determine where the boilerplate ends, i.e. skipping navigation blocks, headers, footers, and sidebars, the evidence I've examined suggests that it would be more reliable to have authors mark up those blocks than mark up the main content. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. On what basis do you draw that conclusion? For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If it's a pull quote, why would you _not_ want it excluded? On Wed, 7 Nov 2012, Ojan Vafai wrote: This idea doesn't seem to address any pressing use-cases. I don't expect authors to use it as intended consistently enough for it to be useful in practice for things like Safari's Reader mode. You're stuck needing to use something like the Scooby-Doo algorithm most of the time anyways. Exactly. On Thu, 8 Nov 2012, Kang-Hao (Kenny) Lu wrote: [...] another argument, if I understand correctly, is to use article in place of this role. I think the Web is probably full of mis-used article already such that using the first article in document order has no chance to work out, but it would nice if this can be verified, even though I can already imagine that an author is unlikely to mark up the main content with article when the main content isn't an article in English sense. For the jump to the start of the body use case, article and main seem like they'd be misused exactly as much as each other. James Graham wrote: The observation that having one element on a page marked — via class or id — main is already a clear cowpath enhances the credibility of the suggested solution. On the other hand, I agree that now everyone heading down the cowpath was aiming for the same place; a div class=main wrapping the whole page, headers, footers, and all is clearly not the same as one that identifies the extent of the primary content. Right. Studying the data, as I have done in previous threads, has always indicated that there is actually no cowpath here for main. As James says above, these classes and IDs are used for all kinds of combinations of content and headers, content and navigation, just content, etc. If this is any indication, main wouldn't be useful for its stated purpose. So, assuming skip to main is the only use case for main, which I am not sure if Steve agrees, I think the proposal should use strong wording to prevent such misuse and the proposal should include one example of such misuse and explains it. The strength of the wording will have basically no effect, let's be realistic here. Few authors read the spec. It doesn't matter most of the time, because the failure mode if an author uses em instead of var or vice versa is just that the styling will be slightly off or maintenance will be slightly harder. The failure mode for main would be that its entire reason for existing (making a
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst derer...@gmx.ch wrote: Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names. Agreed. Looking at existing uses of div class=main to analyse whether we need a main element really doesn't make sense to me. I firmly believe that class=main is mostly used for CSS purposes and not for semantic (and thus accessibility) purposes. Instead, we should be looking at pages that use xxx role=main or more traditionally in older Web pages use a skip to main link as the use cases for a main element. Sometimes that may co-incide with div class=main, but not in general. Therefore, I don't actually think that the introduction in Steve's document is making a good case for the existence of the element with this sentence: The main element formalises the common practicehttps://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html#commonof identification of the main content section of a document using the id values such as 'content' and 'main'. I'd suggest explaining that there is currently no explicit means of identifying with 100% accuracy what part of a Web page is the single most important part. Instead we have a solution only for accessibility purposes with the @role=main ARIA attribute, or more traditionally by providing a skip to main link on the top of the page. If there was a main element that semantically identified the important part of a Web page, that would improve accessibility, but also enable for example search engines to give that part of a Web page a higher importance. On that latter part: I am always annoyed when a search engine gives me links to a particular topic that I was searching for which is only mentioned in a side bar as some related information. It would be possible to exclude such content if there was a main element. The argument that article and aside etc. will do away with such problems relies on authors actually making use of these elements. I am yet to see that happen - in fact I have seen people that started using these elements go away from them again, since they don't seem to have any obvious advantage. main on the other hand has a very real advantage - immediately for accessibility - and its easier to put a single main element on a page than to introduce a whole swag of new elements. It's the simplicity of that single element that will make it immediately usable by everyone, will reduce the probability of authoring error, and thus make it reliable for search engines and other semantic uses. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Skip to main isn't the only use case :-) FYI, as a web designer, (slap me here) I've almost never designed in a skip to main link. Call me ignorant (probably fitting), but in the real world a new way to markup 'skip to main' isn't on my mind. What does concern me, as a web builder, *every day*, is how I markup the content in-between a header and a footer. Consider the following: In this (real, cutdown) example, I was marking up a series of events on a page. Headers and footers, then … something in the middle. article headerh1, h2, p/header div class=content/div footertime, a.permalink/footer /article In this (also, real) situation, I separated the main content of my page from the 'chrome' of the site, headers, footers, etc. body class=contact nav role=navigation … /nav div role=main class=grid spine header h1Lets talk/h1 pProduct, sales or press enquiries—/p /header form action=# method=post … /form /div footer role=navigation class=grid … /footer /body The fact of the matter is that web authors are already inventing main, daily. Just some examples from the files open behind my mail right now. Happy to provide more! Best, Ben -- On 08/11/2012, at 5:13 AM, Kang-Hao (Kenny) Lu kangh...@oupeng.com wrote: (12/11/08 1:48), James Graham wrote: I think that finding the main content of a page has clear use cases. We can see examples of authors working around the lack of this feature in the platform every time they use a skip to main link, or (less commonly) aria role=main. I believe we also see browsers supporting role=main in their AT mapping, which suggests implementer interest in this approach since the solutions are functionally isomorphic (but with very different marketing and usability stories). I think the argument that the Scooby Doo algorithm is deficient because it requires many elements of a page to be correctly marked up, compared to main which requires only a single element to get the same functional effect, has merit. Hixie's another argument, if I understand correctly, is to use article in place of this role. I think the Web is probably full of mis-used article already such that using the first article in document order has no chance to work out, but it would nice if this can be verified, even though I can already imagine that an author is unlikely to mark up the main content with article when the main content isn't an article in English sense. The observation that having one element on a page marked — via class or id — main is already a clear cowpath enhances the credibility of the suggested solution. On the other hand, I agree that now everyone heading down the cowpath was aiming for the same place; a div class=main wrapping the whole page, headers, footers, and all is clearly not the same as one that identifies the extent of the primary content. Right. So, assuming skip to main is the only use case for main, which I am not sure if Steve agrees, I think the proposal should use strong wording to prevent such misuse and the proposal should include one example of such misuse and explains it. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A plea to Hixie to adopt main
In response to Silvia's comments— I think relying on xxx role= is a pretty good result, I think we need to stretch further. An article is a piece of content that isn't semantically defined on its parents. (right?) Shouldn't we have a way to define this without confusing the main content of the 'page'? On 08/11/2012, at 8:07 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst derer...@gmx.ch wrote: Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names. Agreed. Looking at existing uses of div class=main to analyse whether we need a main element really doesn't make sense to me. I firmly believe that class=main is mostly used for CSS purposes and not for semantic (and thus accessibility) purposes. Instead, we should be looking at pages that use xxx role=main or more traditionally in older Web pages use a skip to main link as the use cases for a main element. Sometimes that may co-incide with div class=main, but not in general. Therefore, I don't actually think that the introduction in Steve's document is making a good case for the existence of the element with this sentence: The main element formalises the common practicehttps://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html#commonof identification of the main content section of a document using the id values such as 'content' and 'main'. I'd suggest explaining that there is currently no explicit means of identifying with 100% accuracy what part of a Web page is the single most important part. Instead we have a solution only for accessibility purposes with the @role=main ARIA attribute, or more traditionally by providing a skip to main link on the top of the page. If there was a main element that semantically identified the important part of a Web page, that would improve accessibility, but also enable for example search engines to give that part of a Web page a higher importance. On that latter part: I am always annoyed when a search engine gives me links to a particular topic that I was searching for which is only mentioned in a side bar as some related information. It would be possible to exclude such content if there was a main element. The argument that article and aside etc. will do away with such problems relies on authors actually making use of these elements. I am yet to see that happen - in fact I have seen people that started using these elements go away from them again, since they don't seem to have any obvious advantage. main on the other hand has a very real advantage - immediately for accessibility - and its easier to put a single main element on a page than to introduce a whole swag of new elements. It's the simplicity of that single element that will make it immediately usable by everyone, will reduce the probability of authoring error, and thus make it reliable for search engines and other semantic uses. Regards, Silvia.
Re: [whatwg] A plea to Hixie to adopt main
On Thu, 8 Nov 2012, Ben Schwarz wrote: What does concern me, as a web builder, *every day*, is how I markup the content in-between a header and a footer. If you just want it for styling purposes, div is perfect. article headerh1, h2, p/header div class=content/div footertime, a.permalink/footer /article Exactly like that (or even without the class, if you just have one per article you can just do article div to select it). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposal: Link prerender events
Hi Whatwg! I'm continuing to work on link rel=prerender, an API in WebKit, implemented by Chrome, which allows applications to request pages be loaded early for faster navigation. This is a leading cause of 0ms navigations on the web! As we've explored this feature, we've continued to add to the API to allow more applications to benefit from prerender, and measure that benefit. At launch time, prerenders lasted 30s in Chrome before being removed to prevent stale navigations. Now, the default is 5m, in part because we use application removal of a link rel=prerender ... element as a signal to kill the prerender, similar to the applet or object element. I just wrote up a short proposal at: http://wiki.whatwg.org/wiki/Link_prerender_events discussing the next idea we're working on. By passing events to applications using prerenders, the applications will better measure their use of prerender, and better control how they are launched (serially or in parallel). The proposal has the details. There's patches already in work to do this in WebKit and Chrome, see https://bugs.webkit.org/show_bug.cgi?id=96474 for WebKit and http://codereview.chromium.org/10918189/ for the embarrassingly out of date Chrome version of this patch. In the current revision of the patch, these events are webkit prefixed. I would rather clear that sooner rather than later, but I'm inexperienced enough not to know when is appropriate. What does whatwg think? Thanks! - Gavin
Re: [whatwg] Improving autocomplete
On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth w...@adambarth.com wrote: When should the UA offer to fill in the form (e.g., to select which address they would like to use for shipping this particular order)? Presumably on page load. It was our experience that making this judgement call is difficult, and giving authors control is better than guessing. There's also technical issues such as dynamically created forms when using page load, or our primary use case which is hidden forms and a button that launches this UI which is very attractive on mobile. So to answer your original question about use cases, we want to make it easy for an author to declaratively describe a data set and then request the information from the browser. Using this we want to make it trivial, especially on mobile, to request the information from the UA to allow faster form filling experiences (ex. shipping forms, payment forms, login forms, etc.) In particular, Elliott wrote: Authors can also display no forms at all to users of a browser who implements this proposal for one click checkout experiences which are important on mobile devices. I guess in that case it would be nice to know the user agent actually did display some UI. Indeed, if the browser is incapable of displaying a UI we should fire an error event. Are we using cancel elsewhere by the way? Fullscreen uses error as suffix for the event type. That's a great idea, I've unified the naming with fullscreen. - E
Re: [whatwg] Incomplete user-input in some input types
A. In such case, make input.validity.typeMismatch true, or B. Introduce new IDL attribute to ValidityState. input.validity.invalidUserInput? 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. On Thu, Sep 13, 2012 at 3:18 PM, TAMURA, Kent tk...@chromium.org wrote: Proposal: Making an input element invalid state if the input has an invalid string specified by a user with browser UI. An invalid string means a string which doesn't match to a required format defined by a type. e.g. If a user typed - to input[type=number], input.validity.valid would be false and form submission would be prevented. A. In such case, make input.validity.typeMismatch true, or B. Introduce new IDL attribute to ValidityState. input.validity.invalidUserInput? This behavior should be applied to the following types: number, color, date, datetime, datettime-local, month, time, and week Background: If an input type is implemented as a text field, it is very hard for UA to reject invalid strings for the type. For example, - is not a valid floating-point number, but UA can't prevent users from typing -. So the field can contain invalid strings though its value IDL attribute is empty. If a user tries to submit the form in such situation, the field is valid unless the required attribute is specified. WebKit clears the invalid string when the field loses focus or the form is submitted. A sanitized value (empty string) is submitted. Opera doesn't clear the invalid string. It silently submits a sanitized value (empty string). IE10 has a behavior similar to WebKit. However if a user type -1abc, -1abc is submitted. I don't like clearing user input. It's not a good user experience. Users don't expect their input strings are cleared by UA. Also, I don't like submitting empty value silently. Users expect their input strings are submitted. I think the best UI is to notify users about a field has an invalid string, and give a chance to correct it. Applying the standard form validation mechanism must be reasonable. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
