Re: [whatwg] Maximum value needed for tabindex
On Thu, 24 Jul 2014 08:10:55 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2014-07-24 8:34, Boris Zbarsky wrote: On 7/24/14, 1:29 AM, Jukka K. Korpela wrote: 1) Keep tabindex unlimited and try to make browsers implement this. This is what we should do, in my totally biased opinion. Even in the best case, it would take several years before the usage share of all current browser versions is small enough. Yes. Trying to promote a 'best practice' not to use big numbers because they don't work will also take time, and people will go on repeating it long after it isn't true anymore - while others will say it's old hat long before that becomes the case. So the question is which is the path of least harm. Are there any use cases for tabindex values greater than 32767? Presumably not real use now (since such values do not work), but are there reasonably imaginable use cases? I find it hard to come up with one. Having 327 marked active items in a page and using tabindex in increments of 100 is already a pretty bad situation, at the level where you should probably be dynamically controlling the things with tabindex. Which in turn means you can use smaller increments, and dynamically manage them. Having 32k items in a page doesn't seem like the real-world problem would be numbering the tabindex, but the fact that there are 32k active things you're trying to manage in a single ordered list… cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Proposal: Inline pronounce element (Tab Atkins Jr.)
On Fri, 06 Jun 2014 14:22:48 +0200, Koji Ishii kojii...@gluesoft.co.jp
wrote:
On Jun 5, 2014, at 22:08, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Jun 5, 2014 at 11:29 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Brett Zamir bret...@yahoo.com writes:
On 6/5/2014 3:05 AM, whatwg-requ...@lists.whatwg.org wrote:
On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris
daniel+wha...@honestempire.com wrote:
...
There is currently no other text-level semantic that I know of for
pronunciation, but we have elements for abbreviation and definition.
As an initial suggestion:
pronounce ipa=??a?p?d?iPad/pronounce
(Where the `ipa` attribute is the pronunciation using the
International Phonetic Alphabet.)
What are your thoughts on this,
...
This is already theoretically addressed by link rel=pronunciation,
linking to a well-defined pronunciation file format. Nobody
implements that, but nobody implements anything new either, of
course.
I think it'd be a lot easier for sites, say along the lines of
Wikipedia, to support inline markup to allow users to get a word
referenced at the beginning of an article, for example, pronounced
accurately.
Is there any reason one cannot use the ruby element for
pronunciation?
Example:
rubyElfriede Jelinekrp (/rprtɛlˈfʀiːdə ˈjɛlinɛk/rtrp)
/rp/ruby
That's adequate for visually providing the pronunciation, but I think
the original request was for a way to tell screen readers and similar
tools how to pronounce an unfamiliar word.
True, but one could still use ruby for its semantics, and visually use
the CSS to hide the pronunciations:
rp, rt, rtc { display: none; }
In general screen readers respect HTML. If you use display:none they will
not render that content. So please do not do that.
Besides, the information is normally useful to people who can see it too -
or who can partially see it.
Screen readers may have supported reading text in rt instead of its
base text when they supported Japanese. At least some screen readers in
Japan does this.
The common use case for Ruby in both chinese and japanese, as far as I
understand, is to provide pronunciation. I don't see why that would be
inappropriate in general.
The last thing I saw in Wikipedia was Ray and Maria Stata Center
(/steɪtə/ stay-ta). This seems like a pretty clear use case for ruby to
me.
There is also the Pronunciation Lexicon Specification which is a W3C
Recommendation, but it would take some effort to get that into browsers,
and the browser world seems to find XML too difficult these days so it may
need to be re-done in another format.
Of course syntax is trivial - you could rebuild it as microdata, or RDFa,
or something. The trick is getting people to agree on something they will
implement. I don't recommend microdata because you can't mix vocabularies,
and you may want to have e.g. schema.org data and pronunciation
information for the same content. But
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Supporting more address levels in autocomplete
On Sat, 01 Mar 2014 02:47:06 +0100, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Feb 2014, Jukka K. Korpela wrote: 2014-02-22 3:03, Ian Hickson wrote: (Note that a lot of people in the UK have no idea how to write their address according to current standards. For example, people often include the county, give the real town rather than the post town, put things out of order, indent each line of the address, etc.) The phenomenon is probably not limited to the UK. Few people even know the current standards (national and international). Well sure, but since we're writing a standard, if our assumption is that people don't know standards, we're not going to reach a useful conclusion. I don't think that is necessarily true. In a lot of the work done on HTML, great care has been taken to minimise the likelihood of people getting things wrong, precisely because we don't expect them to know even this standard as well as we might like. [...] On Mon, 24 Feb 2014, Charles McCathie Nevile wrote: That depends on whether you want to force your customers to think like the Post Office, or whether you prefer to be responsive to your customers. Speaking without data, I suspect that nervousness at not being able to put *what someone thinks* is their address translates fairly readily into a certain amount of failure to proceed with a transaction. I'd love to see real data on this. I can imagine scenarios that would lead this to go both ways. I have only anecdotal evidence (including cases where I have not proceeded - having been burnt by proceeding in the past), but it all runs one way. Before we go looking for people who do international shipping to provide such data, can you outline what sort of scenario goes the other way? I'm assuming you probably don't mean people would be reassured by a form that asks for something which doesn't match what they think they know. Do you mean that you can imagine people being reassured when what they think their address is fits nicely in the form? Or something else I didn't get? On Mon, 24 Feb 2014, Dan Brickley wrote: Who is using the data? Just post offices? Or taxi drivers, pizza delivery bikers, pedestrians? The latter three are unlikely to really need much more depth at the locality level. Again, I am not sure that is true - although I need to think it through more carefully than I have time for right now. Ditto for the rest of the discussion, which I think raises some interesting questions. cheers On Mon, 24 Feb 2014, Evan Stade wrote: Regarding UK addresses, libaddressinput[1], which is used by Google for various products, currently accepts two levels of administrative region for GB: city and optional county. You need two levels, but those aren't it. :-) Counties haven't officially been used in UK addresses since the mid 90s. This would be the first open-ended field name. Do we really want to make this open-ended? What happens if a form has n=1..3, and another has n=2..4? What if one has n=1, n=2, and n=4, but not n=3? I don't know why a web author would do this Web authors do all kinds of crazy stuff. We have to be ready for it such that we never end up forced to introduce weird heuristics. but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just mean the site didn't get the n=1 value. My concern is that authors do something like this: input ... autocomplete=address-line-1 input ... autocomplete=address-level-2 input ... autocomplete=address-level-3 ...and then the user enters their address: 1600 Amphitheatre Parkway Mountain View CA ...and then the user goes to another site: input ... autocomplete=address-line-1 input ... autocomplete=address-line-2 input ... autocomplete=address-level-1 input ... autocomplete=address-level-2 input ... autocomplete=address-level-3 ...and the browser autofills: 1600 Amphitheatre Parkway (empty) Mountain View Mountain View CA ...or some such. How does a site know how many levels to offer? It offers as many as it knows what to do with. It probably wouldn't know what to do with n=5, or n=100, and it's highly unlikely a user agent would return a value for those levels anyway, so practically speaking, n=1 to n=3 should be sufficient for now (although n=4 seems possible in the near future). But I don't see the purpose in setting a limit in the spec. This makes me extremely uncomfortable. We're saying, we don't know how to do this, I hope you do. Why would we be less able to answer this than Web authors? It's not like Web authors are experts in postal addresses. I think we should pick the number that is actually needed, and be firm that that is the number. What should a Chinese user interacting with a US company put in as their address, if they want something shipped to China? They would put in the same address regardless of the nationality of the company, assuming the company is able
Re: [whatwg] Supporting more address levels in autocomplete
On Sat, 22 Feb 2014 05:05:06 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Feb 2014, Kevin Marks wrote: On 21 Feb 2014 17:03, Ian Hickson i...@hixie.ch wrote: Those names come from vcard - if adding a new one, consider how to model it in vcard too. Note that UK addresses can have this too - eg 3 high street, Kenton, Harrow, Middlesex, UK That's actually a bogus UK address. I'm not sure exactly which town you meant that to be in, but official UK addresses never have more than two region levels, and usually only one (the post town). The only time they have two is when the post town has two streets with the same name. The real address, where I grew up, was: 2 Melbury Road, Kenton, Harrow, Middlesex, HA3 9RA Today, the address of that building is: 2 Melbury Rd Harrow HA3 9RA Damn humans, not following specs. Actually UK addresses have a huge amount of leeway, as they are routed by postcode in the main (though I did receive a postcard addressed to Kevin, Sidney, Cambridge once). The post office will deal with all kinds of stuff, sure. But Web forms only have to accept the formal address format, which in the UK only ever has a street, a locality (sometimes), a post town, and a post code. That depends on whether you want to force your customers to think like the Post Office, or whether you prefer to be responsive to your customers. Speaking without data, I suspect that nervousness at not being able to put *what someone thinks* is their address translates fairly readily into a certain amount of failure to proceed with a transaction. Providing specification purity over the concerns of both users and developers trying to use the Web to successfully interact with them seems like a pretty basic mistake to me. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] hit regions: limited set of elements for fallback content
On Fri, 21 Feb 2014 09:47:51 +0100, Steve Faulkner
faulkner.st...@gmail.com wrote:
hixie wrote:
But there's plenty of things which make zero sense as fallback content.
input type=color, for example, simply cannot be sanely implemented in
canvas
I don't want to pronounce on sanity, but I don't think it has ever been a
major criterion for whether people *will* do something on the Web.
And it seems pretty easy to make a colour picker in canvas. I can imagine
that anyone who wanted a specific-purpose color picker (styled to match
the site, or customising the options, or...) would do it in canvas or SVG,
and my guess is the former would be more common...
cheers
Chaals
as implemented input type=color is a button that when activated pops up a
picker dialog. So the following code (as a simple example)
canvas id=myCanvas width=200 height=100
style=border:1px solid #00;
onclick=document.getElementById('button').click();
input type=color id=button
/canvas
in Firefox 30/windows when the canvas is clicked the color picker is
displayed., likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed.
--
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] hit regions: limited set of elements for fallback content
if I do want a select, but I just want a canvas to render it visually? Are Web Components and CSS unable to get the effects you need? Maybe we should be improving those rather than canvas. It's hard to tell without knowing precisely what you want to do. This requests reminds me of customers wanting “page intro in flash.”. And the response reminds me of http://xkcd.com/1319/ If a region has a car theft problem, you don't solve it by giving all the thieves the car keys. You solve it by improving the economy so that thieves have better things to do (like get an interesting job), and you solve the remainder by improving law enforcement. The same applies here. We solve it by providing better tools for custom text editing controls (e.g. better contenteditable APIs), and by making it non-conforming to abuse canvas for this purpose. Only if that actually stops people using canvas for this purpose. I'd suggest a different analogy: suppose your company makes foam pipe insulation and you discover people are buying your product and using it as a swimming pool flotation device. Do you try to stop them from using your product and try to get them to purchase other pool toys, or do you start selling your pipe insulation directly to the sporting goods stores? You might check if the pipe insulation is toxic, first. Actually, our role here is to aniticipate what the insulation suppliers of Shenzhen, Minneapolis, Alberta, Yakutsk, and Badaginnie would do, and try to make sure it works out OK. And while we might disagree about what they *should* do, in practice it seems that some developers will use canvas for almost any kind of rendering, probably including things we can't even imagine. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] The src-N proposal
On Fri, 08 Nov 2013 21:41:57 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 8, 2013 at 12:17 PM, Maciej Stachowiak m...@apple.com wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. ... If you look at primitives that exist today (excluding src-N), the fundamental thing that's missing is ability to have one of several images correctly selected by the browser at preload time. Other than that, the proposed behavior can be faithfully implemented with script. The closest you can get today is to preload your best guess of the right image (by putting it in src and then changing with script), or preload nothing and only start loading once your script runs. Offhand I can't think of a way to solve the preloading problem other than with a selection syntax that can be performed by the browser. Running script before the preloader does its pass would defeat the purpose of the preloader. What Maciej said. Just use scripts is, duh, the obvious answer (and one that people KEEP GIVING OVER AND OVER). The problem is that this gates the picture loading behind a script-loading time barrier, There is another problem, which is that requiring scripts is often far less friendly than providing the functionality in basic markup. One approach to solving it would be to wait for people to use templates or something to match basic marlup to scripts and see what they choose. Which is slow - especially because most of the people capable of driving it will just choose to use bare script so we won't figure out what really works as markup as fast as if we were forced to pick some. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 30 Sep 2013, Rik Cabanier wrote: 'drawCustomFocusRing' returns a boolean that signals the author that he is supposed to draw the focus ring. If you want to rename it, then maybe 'needsFocusRing' is better. 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' On Mon, 30 Sep 2013, Rik Cabanier wrote: Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the user requested high contrast rings. (Since I prototyped it in Firefox which does not have this feature, I forgot about that case) In light of that, maybe it's OK to leave the spec as-is. ' notifyFocusLocation' is just as confusing... Yeah... The current name isn't great, but I don't know what would be better (without making its name an essay or something). Right... On Mon, 30 Sep 2013, Dominic Mazzoni wrote: Yes, but I'm arguing that the high contrast rings is not a good idea and we should drop that part of the spec. Some users have great trouble seeing the default focus rings. yeah. Once that part is gone (or once no browser has plans to implement that part), drawCustomFocusRing no longer makes sense. It's certainly true that if we don't want to support users with poor vision, the API would be simpler. But I don't think that's an option. We don't get to arbitrarily ignore some users. Yes, I hope not :) But drawCustomFocusRing() does more than just draw high-contrast focus rings. It also moves the magnification, moves the screen-reader focus, etc. It does everything drawSystemFocusRing() does other than draw the actual focus ring. So it seems that a real question is whether browsers prefer to deal with two APIs, or allow customisation of the focus ring. which comes down to a question of implementation strategy - do browsers rely on a system focus style, or draw it themselves, feeding from a system default style? Here's my alternative idea, though: how about calling it something like scrollFocusedObjectIntoView, and have the *primary* purpose of the API be to make the browser scroll the viewport, if needed to make sure that the bounding box of the path is visible, if that object is focused. The drawFocusRing spec would be modified to specify that scrolling the viewport is part of the spec, too. How would this differ from scrollPathIntoView() ? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?
On Tue, 20 Aug 2013 19:33:12 +0500, Boris Zbarsky bzbar...@mit.edu wrote: On 8/19/13 7:40 PM, Ryosuke Niwa wrote: Also, http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-maxlength-attribute says if the input element has a maximum allowed value length, then the code-unit length of the value of the element's value attribute must be equal to or less than the element's maximum allowed value length. This doesn't seem to match the behaviors of existing Web browsers The spec bit you quote above is an _authoring_ conformance requirement. That is input maxlength=2 value=abc is not valid HTML and a validator would flag it as invalid. What UAs do with this markup, on the other hand, is defined by the UA conformance requirements, and what they do is allow a value longer than maxlength if it's specified. or http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#maximum-allowed-value-length These are the UA conformance requirements in question. The paragraph should be revised to mention and only mention that the maxlength attribute affects the validation and the user agents may prevent the user from typing more characters than the specified value. The basic question is whether a validator should flag input maxlength=2 value=abc as a conformance error or not. It seems to me like it should. Why? It seems that it generally works in browsers, and has for a long time. On the other hand the use cases I can think of have mostly been taken over by placeholder, and pattern with good labelling, and so on. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] XML data islands related question
On Thu, 08 Aug 2013 01:08:54 +0400, Ian Hickson i...@hixie.ch wrote: On Tue, 6 Aug 2013, Jukka K. Korpela wrote: 2013-08-06 17:45, Ian Hickson wrote: If such an application needs some bulk of text data, it can be included e.g. in script type=text/plain.../script but not in a separate plain text file (included into the application distribution, along with other files) referred to via script src=.../script. This is a frustrating restriction and makes it more difficult to maintain and customize application. If an external plain text file could be used, the data content could be separately managed (requiring knowledge only about the format used). I'm not sure what you mean by application distribution. Why can't a text/plain file by included the same way an image/png file is included? It can be included as a file, but it cannot be used. I can't read it. That is the point. I can use an img element referring to an image file, but I cannot refer to a simple plain text file (or an XML file) in an HTML document in a manner that lets me process its content in scripting. I can only include it via iframe or object, but that's different from accessing its content. I don't understand why XHR doesn't work for you. I can see why not. Imagine an app that wants to collect all my current email when it connects, but is then going to be offline for a day or two (or using the sort of terrible connection common in much of the world where you have something good for ten minutes, and then timeouts for an hour or two). It seems to me that you're trying to figure out how to make offline apps - sort of what appcache was meant to do (and famously did for a subset of use cases, but failed for many cases people thought it should work). I think what you are after is something like the apps that are described by a manifest (being worked on in W3C's webapps group), and runtime model describing security restrictions and what is trusted (in W3C's sysapps group) and general rethinking of how to do what we thought appcache would do (the above plus navcontrollers, and other ideas). chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, 20 Jun 2013 17:31:42 +0200, Mounir Lamouri mou...@lamouri.fr wrote: On 11/06/13 23:46, Albert Bodenhamer wrote: Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. As far as I can tell, CEDEX is never explicitly asked in French web forms. Likely because usually only organisations (companies, school, administrations) use such things and real people only use it when they have to send paper letters to those. Which is not qiute as uncommon as it seems. Mostly, when real people who work in those organisations (companies, schools, and administrations are collectively responsible for a lot of employment in France) have to give a postal address - e.g. to buy physical things, or get real papers delivered to them. I guess that someone that needs to fill out an address with a CEDEX will whether add it to the post code, the city name or simply not mention it. Yeah, when I had to use it (about every second day for a few years) I just added it to the city name. I doubt it is needed to add a new autocomplete value for that given that I doubt that forms have a field for that. I can live with that. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] 2D canvas feature proposal: text decoration
On Fri, 19 Apr 2013 00:48:54 +0400, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 18, 2013 at 1:37 PM, David Dailey ddai...@zoominternet.net wrote: You know, I'm not quite sure why we have text in canvas at all. It's not really text you know -- it's just a bunch of pixels. You can't select it, you can't copy it to the clipboard, it's not accessible without a bunch of effort that authors generally don't use. It's generally illegal in most civilized places. Why not use SVG? It's got text decoration. Text is text. It's just that the more conspiratorial and selfish of the browser vendors back when things were being voted on seemed to push canvas since they already owned it and SVG seemed hard and like they might have to learn something by way of graphics in their corporate portfolios. That's how I see it, anyhow. WHATWG doesn't vote, of course. text ... is generally illegal in most civilized places What is this i don't even Using canvas for serious rendering of text is generally... Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Forcing orientation in content
Hi, On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant bruan...@gmail.com wrote: Hi, Currently working on a web project where tablet support (iPad especially) is important, I'm facing a need which apparently the platform doesn't support. I would need to lock the screen in landscape mode. Not sure if WHATWG is doing anything, but in the W3C there is https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html in the Web Apps group (by Mounir, who works on Firefox OS as a day job) I expect to know a bit more about the implementation status of this in about a week, when the group has a face to face meeting. cheers Chaals I've been searching and StackOverflow suggested this is not possible [1][2][3][4]. The best solution that I have read online was to listen to orientation changes, update an orient attribute (on body or html) and change the CSS based on that. Or Media Queries. But I don't really want to play with either JavaScript or CSS, I don't really know why I should. Especially given that in some comments [1], it is suggested that it is possible to lock the orientation in native apps. Beyond my current project, I have participated to a FirefoxOS app days in Bucharest (helped people developing their apps mostly answering their questions). A participant wanted to port his website (games for ~5yo kids) as an FirefoxOS app and told me clearly that if he had no way to lock the screen in landscape, he wouldn't be interested in FirefoxOS (pretty sharp opinion, but that's what he said). Fortunately, that's possible, but one has to use metadata to do so [5]. So I feel the need is there. I was wondering if it would be possible to add a meta (or whatever else is felt more relevant) to lock the orientation declaratively. It sounds like an information that belongs to the head. I feel the FirefoxOS experience [5] sets a good example. Thanks, David [1] http://stackoverflow.com/questions/2772691/is-it-possible-to-prevent-iphone-ipad-orientation-changing-in-the-browser/2772748#2772748 [2] http://stackoverflow.com/questions/8738072/forcing-web-site-to-show-in-landscape-mode-only [3] http://stackoverflow.com/questions/3217805/force-orientation-on-ipad-javascript [4] http://stackoverflow.com/questions/1207008/how-do-i-lock-the-orientation-to-portrait-mode-in-a-iphone-web-application [5] https://developer.mozilla.org/en-US/docs/Apps/Manifest#orientation -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Is main now an official HTML5 element?
Hi Ian, On Thu, 14 Feb 2013 01:31:36 +0100, Aurelio De Rosa aurelioder...@gmail.com wrote: I think this should answer your question: http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F It doesn't seem to provide much useful information on the differences. According to its charter http://www.whatwg.org/charter, WHAT-WG is a group of 9 individuals who work with a very simple set of rules (basically the editor of a specification decides what should be in it, but the 9 people can decide other things by overwhelming majority). There is a mailing list, IRC, etc, and everyone else who contributes to the discussion is called a contributor. More about how WHAT-WG works is described at http://wiki.whatwg.org/wiki/FAQ The HTML WG is one of the working groups of W3C. The working group has a charter that describes some of how it works: http://www.w3.org/2007/03/HTML-WG-charter W3C itself is a consortium of member organisations, and the links from the HTML WG charter to the process document will lead you into more information about how W3C works. Note that in my personal opinion the Wikipedia page about W3C is outdated and very poor quality information. cheers Chaals Best regards 2013/2/14 Ian Yang i...@invigoreight.com Hi Steve, Thanks. And sorry, but til now I still don't understand the differences between whatwg and html wg. Could you please explain? Regards, Ian On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, I cannot speak for whatwg, but from the W3C HTML spec side the main element is in the HTML 5.1 spec and has been implemented in browsers and so will be added to HTML5 spec at some point as it likely meets the CR exit criteria. as for it being a sectioning element, there is currently an open bug on that, which we be dealt with. If you want to discuss the specification of the main element in HTML 5.1 specification feel free mail the html wg list. If you want to discuss definition as per the whatwg spec this is the place, although I will obviously follow ant discussions with interest regards SteveF Date: Wed, 13 Feb 2013 18:31:32 +0800 From: Ian Yang i...@invigoreight.com To: whatwg wha...@whatwg.org Subject: [whatwg] Is main now an official HTML5 element? Message-ID: CABr1FsfcaX8=B8TReG8Sz36W= h1w0hRY61+LG=cebo-zuwy...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi editors and all other folks, I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? However, in spec, it still says that main element is not a sectioning element. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? Sincerely, Ian Yan -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, 29 Jan 2013 11:28:01 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 28, 2013 at 11:41 PM, Olli Pettay olli.pet...@helsinki.fi wrote: WebSocket, EventSource etc ctors do have side effects. Exactly. And if we designed XMLHttpRequest from scratch it would have them too. Really? This doesn't seem like a good idea, so I'd be interested to know why. Is there an explanation laid out somewhere? cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Use of article to identify the main content of a web page (was Re: A plea to Hixie to adopt main)
On Mon, 19 Nov 2012 15:38:26 +0100, Ian Yang i...@invigoreight.com wrote: On Mon, Nov 19, 2012 at 8:40 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, hixies suggestion to use article to act as a main content identifier [3] is incorrect, as per the HTML spec [1] The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. The main element as per the main element spec [2]: The main element represents the main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. The article and main roles as defined in ARIA have distinct characteristics and those distinctions are also expressed via how they (and the article element) are exposed via accessibility APIs in browsers. [1] http://dev.w3.org/html5/spec/the-article-element.html#the-article-element [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html [3] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0221.html Thanks Steve for explanation. Could you please suggest an appropriate element for the wrapper of the content of a blog post? I'm not Steve. But I've been looking at the proposal. So IMHO... If it is a single post on a page, you could wrap it in article or in main. If it is a forum, where multiple threads are displayed, you would wrap each in article. Main would cover the collection of threads on the page (but not the navigation etc.) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Use of article to identify the main content of a web page (was Re: A plea to Hixie to adopt main)
On Mon, 19 Nov 2012 15:38:26 +0100, Ian Yang i...@invigoreight.com wrote: On Mon, Nov 19, 2012 at 8:40 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, hixies suggestion to use article to act as a main content identifier [3] is incorrect, as per the HTML spec [1] The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. The main element as per the main element spec [2]: The main element represents the main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. The article and main roles as defined in ARIA have distinct characteristics and those distinctions are also expressed via how they (and the article element) are exposed via accessibility APIs in browsers. [1] http://dev.w3.org/html5/spec/the-article-element.html#the-article-element [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html [3] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0221.html Thanks Steve for explanation. Could you please suggest an appropriate element for the wrapper of the content of a blog post? I'm not Steve. But I've been looking at the proposal. So IMHO... If it is a single post on a page, you could wrap it in article or in main. If it is a forum, where multiple threads are displayed, you would wrap each in article. Main would cover the collection of threads on the page (but not the navigation etc.) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Use of article to identify the main content of a web page
On Mon, 19 Nov 2012 19:08:05 +0100, Ian Hickson i...@hixie.ch wrote: On Mon, 19 Nov 2012, Ian Yang wrote: On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Nov 2012, Ian Yang wrote: That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. That's called article. Thanks Hickson. Actually I had turned down my own opinion ( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html ). And isn't article used to wrap an entire blog post? Like this: article header / div / footer / /article Right. It wraps all the elements of a blog post. All the ps, uls, ols, figures, tables, h1s, footers, etc. Sure, but what about multiple articles, in a page like the front of a US newspaper or a forum page with multiple threads, or the front page of my blog (which offers the last n articles on the same page)? If you just want to wrap a subpart of that for rendering purposes, div is the element you want. Basically div is always the answer if the question is how do I provide myself a hook for CSS styling. Sure, but that isn't the question I have. I'd like to know what is the main content of the page? There are a set of use cases that have some overlap (but not a whole lot), where I'd like to seperate out articles in the sense of things - like things in a newsletter or things that people are talking about. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Improving autocomplete
On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak m...@apple.com wrote: The key questions. I've added some more comments... (1) If this API fills in a form completely based on stored data, and not by completing the user's typing, then it is autofill rather than autocomplete. Yep. (2) If this API provides the ability to get user information without even having a visible form, then it's not clear that it is even really autofill. It's just requestUserInformation() or something. Right. It's like openly shared super-cookies... (3) This API has important privacy and even security considerations. Yes. You have to tell the user exactly what you are going to fill in to the site before they approve. And because as soon as you put it into the input field the site can use it, as a basic security measure it seems like you should never autofill without explicit user confirmation. Unfortunately, most won't read it. Indeed. If sites are asking for so much info that they have to split pages for usability, then it seems likely the UI that tells the user what the site is asking for will be impractical for most users to meaningfully review. Yes. This is a problem I face from time to time, and I think its seriousness is underestimated. This process can be used to collect all sorts of information before the user realises they didn't want to hand it over. This becomes especially dangerous if the mechanism can fill in credit card info. That assumes your most valuable info is about your credit card, which is only the case for a certain proportion of people. I would be very nervous if the browser could at any moment pop up a dialog that would submit all my credit card info to a dubious site if I slip and click the wrong button. Can you expand more on what thought you have given to the security considerations? (4) Should this API be limited to initiation during a user interaction? Yes... That would reduce the ability of sites to spam the user with such forms. (5) What makes the UI unspoofable? Is that an important part of the security model? cheers Chaals Regards, Maciej On Oct 26, 2012, at 12:24 AM, Elliott Sprehn espr...@gmail.com wrote: Several of us on the Chrome team have been thinking about the challenges of filling out long forms full of personal information. We've noticed that site authors split up their forms across multiple pages to avoid overwhelming their users with one single massive form [1]. This is particularly bad on mobile where we've observed some popular retailers splitting their forms into six or more pages in an attempt to optimize their flow for a small screen. This unfortunately defeats many of the advantages of existing browser autocomplete. In researching this we’ve found that with a few changes built on the existing HTML autocomplete spec [2] we can allow authors to recombine their forms and enable browsers to provide more useful autocomplete. 1) HTMLFormElement.prototype.requestAutocomplete() Asks the user agent to asynchronously present a UI for performing full form autocomplete using the already spec’ed autocomplete attributes [2] used in the form. In concept this is very similar to prompt() except the UA could provide a streamlined experience for filling in information in large chunks. For example you could imagine choosing a shipping address from a drop down instead of presenting multiple inputs. 2) Simple event named “autocomplete” This event is dispatched on the form element after the UI presented by requestAutocomplete() is closed if the form validates after having filled each input and firing all necessary input events like “change”. 3) Simple event named “autocompletecancel” This event is dispatched on the form if the UI is canceled. Using this API authors may simplify their input flows from forms spread over multiple pages to just a few clicks on a single page all while getting all the autocomplete goodness! 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. The proposed additions also improve security on the web as users will become accustomed to inputting their sensitive data through an unspoofable UI that could warn users of phishing sites or even allow them to choose per domain security images. We’d love to hear the thoughts of other implementers on this proposal. :) [1] ex. Retailers often split forms into credit card, billing address, and shipping address pages. [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete - E -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] content element, which we need in our documents
on what this element would do and/or mean? It would act as a grouping construct (a la div, section, or article) for the primary content of a page. It could be used for navigation of a page by blocks (see the discussions on tabindex scope and navigation cycles and mechanisms in HTML, and before that in SVG), for indexing content across a site, for adaptation to different layouts, or whatever else has motivated the people who have been using a div to identify their main content. It is more or less impossible to define that exhaustively (since it depends on the author's judgement of what their main content is), a working explanation of what it isn't should be sufficient. In case this element does seem warranted, I would offer as a starting point This element identifies the principal content of the page. It is designed to exclude page components such as site navigation, comments, headers and footers, and others that are common to a number of different pages. I'm sure smart people can improve that significantly. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
