Re: [whatwg] Dynamic content accessibility in HTML today
Matthew Raymond wrote: Show me a spec that says that in a normative way. It is merely a best practice. Class names, in general, are meaningless and meaningful class names should not be part of the core specification. The reason that semantic class names are best practice is because class names that are purely for presentational effects are less useful when using alternate or user style sheets. That's a purely human factor though. There's no reason you can't use div class=bigredtext and style it with an Aural style sheet. Or indeed with a visual stylesheet to present the text in small, blue letters. It's just /likely/ to make your document harder to understand if you do that. In fact, a presentational class name might be applied to elements that have different semantics just because the author wanted to use the same style for all the elements, giving the impression that elements are related even when they're not. That would be an acceptable use of class. It would probably be poor design (because later the author might want to restyle the elements separately) but that's not our problem. Indeed a nominal requirement that class names map to semantics would be impractical; there exists no 1:1 mapping between the semantics of an element and the way it is presented within a particular document (e.g. I might want 7 h2 elements 3 being styled with a left float and red text and 4 being styled with a right float and green text). Any attempt to formalise the class attribute beyond it takes arbitrary values is imho misguided and doomed to failure. Of course, if you plan to put all the semantics of a document in the class names, we could do away with many elements. Do you object to div class=h1 as a replacement for h1? Your example only makes sense if you assume a mix of presentational names and semantics names as class values. For authors that use only semantic class names, the example is meaningless. ? The values for |role| are nothing more than a new set of class names, and there is nothing preventing the user from putting in unidentified |role| values for presentational purposes and then styling them via CSS using attribute selectors. So aside from being mildly harder to select from CSS, |role| values are potentially no more semantic than |class| values. Authors can misuse anything. h1 style=font-size:12px; font-weight:normal;This is the main text of my document put in a heading so that search bots think that it's really relevant and useful/h1. What you fail to understand is that user agents will have to have means of handling the misuse, No. I'm pretty sure I do understand that. which means that many of the differences between |role| and |class| are more conceptual than practical. Not really (but don't take that as meaning that conceptual differences are unimportant! The difference between semantics and presentation is more conceptual than practical: a human will get the semantics - what is a header and what isn't, for example - from the presentation, not the 'semantics' embedded in the markup). Practically, class is an attribute in widespread use without any regard for the information required by accessibility tools. That means many pages could already be using class=tab where their role attribute would be tabpanel. Practically the class attribute is valuable in making arbitrary groups of elements suitable for selection by CSS or scripts - this has nothing to do with semantics of any kind. Practically, the presence of a role attribute implies that a group of elements should be interpreted as a particular component of a UI widget, significantly altering the interpretation of that subtree - justification enough for a new attribute (and, in some cases, for whole new /elements/)- and that other attributes on the element will be interpreted as ancillary information about that widget. However, let's assume that people would only use semantic values in |role|. What becomes of |class|? We use it only for styling? That won't work, because HTML is supposed to be semantic. We use it for it's purpose - to provide hooks to enable presentational languages to couple to arbitrary groups of elements on a page. This kind of non-semantic hook is _necessary_ so that the temptation to abuse the semantic elements is greatly reduced. The use case for such classes will become progressively smaller as XBL2 is introduced and CSS improves. Why do anything today when in several decades you might not have to bother? I mean it's just happenstance that no-one is expected to need an assistive technology until 2050 or whenever CSS4+XBL2 are maturely implemented and, through a programme of extensive brainwashing, authors start doing the correct thing rather than the easy thing. So what we end up doing is replacing |class| with an attribute named |role| that has more rules but otherwise does the same thing. No. We add an attribute which conveys
[whatwg] input type=country?
There are times I have to select in which country I live in. Wouldn't a input type=country widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. Regards, Martijn
Re: [whatwg] input type=country?
On Wed, 23 Aug 2006 20:44:37 +0700, Martijn [EMAIL PROTECTED] wrote: There are times I have to select in which country I live in. Wouldn't a input type=country widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. What would be different between input type=country and select? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] input type=country?
Alexey Feldgendler wrote: On Wed, 23 Aug 2006 20:44:37 +0700, Martijn [EMAIL PROTECTED] wrote: There are times I have to select in which country I live in. Wouldn't a input type=country widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. What would be different between input type=country and select? I presume he's thinking of an input with a browser-supplied list of countries. This has been discussed before as, as I recall, was considered a huge can of worms that we don't want to open. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] input type=country?
On Wed, 23 Aug 2006 20:51:25 +0700, James Graham [EMAIL PROTECTED] wrote: There are times I have to select in which country I live in. Wouldn't a input type=country widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. What would be different between input type=country and select? I presume he's thinking of an input with a browser-supplied list of countries. This has been discussed before as, as I recall, was considered a huge can of worms that we don't want to open. Could you point to that discussion in the archive? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] input type=country?
Alexey Feldgendler wrote: On Wed, 23 Aug 2006 20:51:25 +0700, James Graham [EMAIL PROTECTED] wrote: There are times I have to select in which country I live in. Wouldn't a input type=country widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. What would be different between input type=country and select? I presume he's thinking of an input with a browser-supplied list of countries. This has been discussed before as, as I recall, was considered a huge can of worms that we don't want to open. Could you point to that discussion in the archive? See e.g. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001775.html and followups (this isn't the first post in the thread but the thread title seems to have changed or something so I didn't find the very start - I think it's good enough though) -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] input type=country?
On 8/23/06, Martijn [EMAIL PROTECTED] wrote: On 8/23/06, Arve Bersvendsen [EMAIL PROTECTED] wrote: On Wed, 23 Aug 2006 15:44:37 +0200, Martijn [EMAIL PROTECTED] wrote: There are times I have to select in which country I live in. Wouldn't a input type=country widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. Which countries we have in the world, and how they are named is a rather volatile property. Countries change name depending on the current rule(r), and as not-too-distant European history taught us, countries break up. The definition of what is a country varies depending on who you ask, so such a form control is hard to accomplish. Well, the browser should be able to keep up with the current list of countries, shouldn't it? It's not like it is something that is changing every minute. But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? -- David Håsäther
Re: [whatwg] input type=country?
David Håsäther wrote: But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? Many modern browsers already periodically check for updates. Such lists could be downloaded like any other update, as required. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=country?
On 8/23/06, Martijn [EMAIL PROTECTED] wrote: On 8/23/06, David Håsäther [EMAIL PROTECTED] wrote: Well, the browser should be able to keep up with the current list of countries, shouldn't it? It's not like it is something that is changing every minute. But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? That could happen nowadays also, that a country isn't listed in the select control. Indeed, I would think that the browser would keep up with a list of available countries. Yes, this is why it's probably not a good idea to use a select list for contries, since there is a possibility that your country is not on the list. -- David Håsäther
Re: [whatwg] input type=country?
On Wed, 23 Aug 2006 21:24:52 +0700, David Håsäther [EMAIL PROTECTED] wrote: But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? That could happen nowadays also, that a country isn't listed in the select control. Indeed, I would think that the browser would keep up with a list of available countries. Yes, this is why it's probably not a good idea to use a select list for contries, since there is a possibility that your country is not on the list. Web Forms 2.0 provides a datalist element which can be used to supplement a free-form text input with a list of suggested values. Also, we should not forget that Web Forms 2.0 allows datalist and select to have a data attribute which references an external list of choices. Hosting the list of countries once per website seems like a good solution. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] input type=country?
On 8/23/06, Stewart Brodie [EMAIL PROTECTED] wrote: But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? That could happen nowadays also, that a country isn't listed in the select control. Indeed, I would think that the browser would keep up with a list of available countries. Who would look after this list? The U.N.? Not all countries in the world are members of the U.N. In which languages will this list be maintained? What am I supposed to do if I'm not on an Internet-connected node? I would think the list is in the same language as the browser. I don't see a reason why you should be connected to the internet to be able to show the input type=country widget (although for submitting forms it is often necessary). Yes, I know there are political problems, with a list of countries, so there is an issue there. Regards, Martijn This sort of 'official list of all possible answers' thing is already a very real problem for interacting with websites of less enlightened companies and organisations (primarily in the United States, but I've found a few in other countries as well, though). I'm asked to choose a country from the supplied list, but even though I've selected 'United Kingdom', the form still refuses to submit because it requires me to say which of the 50 U.S. states I'm in! -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] input type=country?
On Wed, 23 Aug 2006 16:36:44 +0200, Martijn [EMAIL PROTECTED] wrote: You can have a select list and an input control at the same time, not? See Lachlan Hunt's suggestion elsewhere in this thread, he uses: input type=text name=country list=country-list select name=country-list id=country-list [...] /select This gives you an input type=text that has an attached dropdown with your suggestions. With unobtrusive scripting, you could filter this list automatically as the user types (by setting the disabled attribute on non-matching options. -- Arve Bersvendsen, Opera Software ASA, http://www.opera.com/
[whatwg] Workflow and web applications
How do you get workflow in a Web Application using only Web Browser technology, Microsoft I think is the only company which will bring a workflow to the masses, Using a combination of Dojo widgets we can achieve something very similar see this URL http://showoff2.awardspace.biz/pack/pack/examples/tabswitch2.html From a MVC design concept XForms in conjunction with XML Event (xmlns = http://www.w3.org/2001/xml-events" ) becomes the controller. Regarding input = country, you can have XForms select1 control with type =open, the control supports nodeset which can be downloaded via "services" or use XInclude to bring in the countries set. Regards Francisco smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Workflow and web applications
On 23/08/06, Francisco Monteiro [EMAIL PROTECTED] wrote: How do you get workflow in a Web Application using only Web Browser technology, Microsoft I think is the only company which will bring a workflow to the masses, Using a combination of Dojo widgets we can achieve something very similar see this URL http://showoff2.awardspace.biz/pack/pack/examples/tabswitch2.html That page took about 20 seconds to load on my corporate network. And then it didn't work. I got dojo is undefined. -dean
[whatwg] Some comments on server-sent events
* The event-source element has no DOM interface while it has some attributes that probably warrant one. * The specification doesn't define when the onevent event handler is invoked nor when the event event is dispatched. They are only defined. It's also unclear which interface they implement, et cetera. * A problem with the event-source element is that the resource is loaded before you can attach event listeners to the document. Perhaps the loading should start after the load event is dispatched? Unless the element was inserted into the document of course (that's actually also a bit unclear). * Since event sources can be attached using other ways than using the event-source element the Target field should be amended to take that into account. (Some sentences there don't make sense for an event source attached to an object that is not an event-source element.) * Regarding that, I'd be interested in hearing the use case for allowing any EventTarget to be a source for server-sent events. * Event namespaces throughout should be changed to match DOM Level 3 Events. That basically means that http://www.w3.org/2001/xml-events is gone. * Perhaps RemoteEvent should be replaced with a reference to CustomEvent from DOM Level 3 Events which offers the same type of functionality? * What happens when the event given in the Event field doesn't match the NCName production as required by DOM Level 3 Events such as in the example in section 7.1.7? (It uses the event stock change.) * At the moment the BNF does need error handling because you could have a ; at the start of a line without any data following (or a new line for that matter). * It might be better to replace the BNF with something similar as the HTML parsing specification currently has. That provides a much more clear processing model. * What happens for other line feed characters? Are they treated as fields? Won't that give lots of problems for authors coding in non-Unix formats? HTTP for example allows both. * For each non-blank, non-comment line, the field name is first taken[...] doesn't cover what happens to command lines. * The ctrlKey field would be ignored[...] should probably say keyIdentifier as that's what's used in the example. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Web Forms 2.0 is now a W3C Working Draft
Slightly off-topic - what I like most is this ultra-sensitive and tactful for example the activation code for a nuclear weapon [1] Impressive. [1] http://www.w3.org/TR/web-forms-2/#the-autocomplete -- Jens Meiert http://meiert.com/ Webdesign mit CSS (O'Reilly, German) http://meiert.com/cssdesign/
Re: [whatwg] input type=country?
On Aug 23, 2006, at 5:08 PM, Dean Edwards wrote: On 23/08/06, Arve Bersvendsen [EMAIL PROTECTED] wrote: On Wed, 23 Aug 2006 16:02:24 +0200, Martijn ... I'm sure there is an official list out there (United Nations?), with all the countries in the world. What happens when a web developer lives in a part of the world doesn't agree with the 'official' list of countries? You use a select. ... Or, if you're using Web Forms 2 anyway, a datalist. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [wf2] Filtering datalist with pattern
On Fri, 26 May 2006, Matthew Raymond wrote: Henri Sivonen wrote: The WF2 spec does not say anything about filtering autocomplete lists on pattern and Opera 9 does not do it. However, autocomplete entries that would fail form validation are not particularly useful. I suggest saying that potential autocomplete items (whether supplied by the UA itself or read from a datalist) should be tested against the datatype and the pattern of the form field being filled and should only be shown if they match both the datatype and the pattern. This assumes that the inclusion of such items is unintentional. What if you wanted the user to be able to select from a fixed set of values that fall outside of the pattern in addition to those that fit the pattern? Is the proper way to handle this to force web authors to write these values into the pattern? This could be rather troublesome if you have a significant set of nonconforming datalist values. Could you give an example of this? It seems like the common cases, like picking named values, would be handled by label= vs value=: 1:input type=number name=gauge list=gauges min=0 step=any datalist id=gauges option label=Z value=220 option label=N value=160 option label=HO value=87 option value=8 /datalist -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=country?
Martijn wrote: On 8/23/06, David Håsäther [EMAIL PROTECTED] wrote: But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? That could happen nowadays also, that a country isn't listed in the select control. Indeed, I would think that the browser would keep up with a list of available countries. Screw the browser! What happens if the _SERVER_ doesn't have a specific country name, or expects a name you don't use. You're assuming that the country is just a string of text that's stored on the server in the same way someone's name is, but that may not be the case. Even if you were to keep your country list on the server in synch with the list on a browser, which browser do you synchronize with? Are all the browser vendors supposed to form a central authority to decide what all the country names are? Do they maintain different lists for different locales? Even if they did maintain different lists for different locales, the server would have to be notified as to which locale you're using. Also, how would you refit the old sites to the new system? Are you going to rewrite all your Perl scripting to use the new widget? This whole thing sounds about as fun to spec and implement as whacking yourself repeatedly between the eyes with a ball pin hammer.
Re: [whatwg] [wf2] Filtering datalist with pattern
Ian Hickson wrote: Could you give an example of this? It seems like the common cases, like picking named values, would be handled by label= vs value=: 1:input type=number name=gauge list=gauges min=0 step=any datalist id=gauges option label=Z value=220 option label=N value=160 option label=HO value=87 option value=8 /datalist Yeah, I suppose that would be fine, except for extremely rare cases where the value absolutely has to be outside the pattern. The following don't have fixed-length numeric values, for instance: | datalist id=math | option label=i value=sqrt(-1) | option label=pi; value=pi | option label=e value=e | /datalist I'm not entirely sure if they're a big enough deal to bother with. The |label| attribute really would fix most problems. Now all we have to do is get a vendor to implement |label| properly. :(
Re: [whatwg] [wf2] Filtering datalist with pattern
On Thu, 24 Aug 2006, Matthew Raymond wrote: Yeah, I suppose that would be fine, except for extremely rare cases where the value absolutely has to be outside the pattern. The following don't have fixed-length numeric values, for instance: | datalist id=math | option label=i value=sqrt(-1) | option label=pi; value=pi | option label=e value=e | /datalist I'm not entirely sure if they're a big enough deal to bother with. You could deal with pi and e easily enough even then, just by rounding the given value and then looking for that particular value as a magic number in the submission handling and then treating them as pi/e. It's a hack, but it works. That doesn't handle i, but I have yet to see a form that asks me to select a number and gives specific imaginary numbers as an option (as opposed to accepting any complex number, at which point there's no problem again). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
