Re: [whatwg] Storage mutex
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote:
First of all, I was wondering why all user prompts are specified as must
release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
really say must instead of may? IIRC (I couldn't find the original
thread, unfortunately) this was added because of deadlock concerns. It
seems like there might be some UA implementation specific ways this could
deadlock and there is the question of whether we'd want an alert() while
holding the lock to block other execution requiring the lock, but I don't
see why the language should be must. For Chromium, I don't think we'll
need to release the lock for any of these, unless there's some
deadlock scenario I'm missing here.
So if one page grabs the lock and then does an alert(), and another page
in the same domain tries to get the lock, you're going to let the latter
page hang until the user dismisses the alert in the first page?
Yes. And I agree this is sub-optimal, but shouldn't it be left up to the
UAs what to do? I feel like this is somewhat of an odd case to begin with
since alerts lock up most (all?) browsers to a varying degrees even without
using localStorage.
That behaviour sounds worse than what Firefox currently does, where an alert
disables input to all tabs in the window (which is already pretty bad),
because it willl make applications in visually unrelated tabs and windows
hang.
Given that different UAs are probably going to have other scenarios where
they have to drop the lock (some of them may even be purely implementational
issues), should we add some way for us to notify scripts the lock was
dropped? A normal event isn't going to be of much use, since it'll fire
after the scripts execution ends (so the lock would have been dropped by
then anyway). A boolean doesn't seem super useful, but it's better than
nothing and could help debugging. Maybe fire an exception? Are there other
options?
A generation counter might be useful.
Ooo, I like that idea. When would the counter increment? It'd be nice if
it didn't increment if the page did something synchronous but no one else
took the lock in the mean time.
Defining no-one else may be difficult. I haven't thought this through, to
be honest, but I think you could update the counter every time the storage
mutex is released and the shared state was modified since the storage mutex
was acquired. Reading the counter would acquire the storage mutex. You'd
basically write
var counter = window.storageMutexGenerationCounter;
... do lots of stuff ...
if (window.storageMutexGenerationCounter != counter) {
// abort, or refresh local state, or something
}
I'm not sure what you'd do if you discovered an undesired lock-drop, though.
If you can't write something sensible instead of abort, or something, it's
not worth doing.
But getStorageUpdates is still not the right name for it. The only way
that there'd be any updates to get is if, when you call the function,
someone else takes the lock and makes some updates. Maybe it should be
yieldStorage (or yieldStorageMutex)? In other words, maybe the name should
imply that you're allowing concurrent updates to happen?
I thought that's what getStorageUpdates implied :-).
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, Aug 22, 2009 at 7:37 AM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Xiph has spent a long time on developing libraries that make seeking simple for Ogg Theora/Vorbis and Firefox has the advantage of using these libraries. In fact we had to write this support ourselves. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Comments on the definition of a valid e-mail address
Aryeh Gregor writes: Historically, MediaWiki has mostly just required that an @ symbol be present in the address. Originally we used a simplistic regex, It's relatively well known that a simple regex can't be used to match e-mail addresses (and not match things that aren't!); Jeffrey Friedl's 'Mastering Regular Expressions' (O'Reilly) included a pattern for this over a decade ago, but it is exceedingly long: http://groups.google.co.uk/group/comp.lang.perl.misc/msg/603ba6fc642a3124 http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html ... but when users complained, we looked into the RFCs and decided it was too complicated to bother with validation beyond checking for an @ sign. It's too complicated for most developers to roll their own validation, but there are standard libraries available which get it right. ... I decided to do some research on how many users' addresses would be invalidated [by HTML 5's validation] ... 1) Addresses in the form foo b...@baz.example, or similar. These mostly match RFC 5322's name-addr production instead of addr-spec Forms on websites capturing users' e-mail addresses typically want just the address part, prompting for the human-readable name in a separate box, so I think HTML 5's input type=email not allowing the above is helpful. 2) Addresses with dots in incorrect places, in either the local part or the domain name part. For instance, multiple consecutive dots, or leading/trailing dots. These don't match RFC 5322 at all AFAICT, but I asked one of the users with an invalid address of the form f...@example.com, and he said it worked fine for him. GNU mail gave a syntax error when I tried to send mail to that address, but Gmail sent it without complaint, and the user received it successfully. There may actually be several categories of oddly placed dots. While the address in the form you give above works it may be, say, that those with repeated dots in the hostname part don't work. On the specific case of a . immediately before the @, I've seen that before: this Perl library module extends an RFC-compliant module to allow just that; its author admits .@ breaks the RFCs but claims such breakage is useful in the real world, specifically when dealing with e-mail addresses for Japanese mobile phones: http://search.cpan.org/perldoc?Email::Valid::Loose That somebody has found this to be a sufficiently widespread problem with standard Perl e-mail address validation to write and upload a module which 'fixes' this (and just that; it makes no other changes) suggests that people will find HTML 5's input type=email to be problematic in precisely the same way. There were other types of addresses that didn't meet HTML 5's specification after whitespace was stripped, but none with more than a single-digit number of addresses occurring in the sample of three million or so that I looked at. So it may actually be that there isn't a general problem here of lots of real-world e-mail addresses which work but don't comply with the RFCs; it may simply be the one case of .@? There aren't a plethora of Email::Valid extensions which relax various different criteria; just the one which allows .@. Alternatively, you could just loosen the restrictions even further, and only ban input that doesn't contain an @ sign. (Or that doesn't match ^...@]+@[...@]+\.[^@]+$, or whatever.) Or just don't ban anything at all, like with type=tel. type=email differs from most of the other types with validity constraints (like month, number, etc.) in that the difference between valid and invalid values is a purely pragmatic question (what will actually work?) that the user can often answer better than the application. It doesn't seem like a good idea for the standard to tell users that the e-mail addresses they've actually been using are invalid. Users often mis-type e-mail addresses. It seems useful to be able to trap as many typos as possible. Many authors obviously believe this, given how many employ JavaScript validators. If HTML 5 were overly permissive about input type=email then it's likely such authors would continue to use homegrown JavaScript solutions, which slightly defeats the purpose of HTML 5 introducing input type=email). Smylers
Re: [whatwg] Orientation event in Firefox
Hi Doug, What do you think about the proposal in [1]? Some discussion is needed on WebApps for this topic to move forward. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Doug Turner Sent: Monday, August 24, 2009 5:40 AM To: wha...@whatwg.org; public-device-a...@w3.org Subject: Orientation event in Firefox I posted some thoughts and a strawman for orientation in Firefox: http://dougt.org/wordpress/2009/08/orientation/ Regards, Doug Turner Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
[whatwg] small element should allow nested elements
Hixie wrote: Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. Fair enough. But in that case, I think perhaps the spec could do with a bit of rewording for the small element. The current wording: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. ...sounds like an *exact* fit for Remy's use case: So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p Does anyone have any ideas on a rewording of the definition of the small element to make it clear that it is only intended for certain instances but not others? Alternatively, does anyone else think the small element should be capable of wrapping inline and block elements? (raises hand) -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Orientation event in Firefox
On Mon, Aug 24, 2009 at 10:41 AM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Doug, What do you think about the proposal in [1]? Some discussion is needed on WebApps for this topic to move forward. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html For the record, see also: http://browserplus.yahoo.com/developer/explore/?s=Motion Demo: http://browserplus.yahoo.com/demos/marbles/intro It isn't based on events (you have to poll continuously) and uses values ranging from -127 to 128 (well, it's rather bizarre: x seems to range from -127 to 128 while y ranges from -128 to 127! –I can't say for z as my laptop doesn't have an accelerometer–) And it has a fallback on mouse: 0,0 being the center of the screen (128,-128 being the top-left corner, and -127,127 the bottom-right corner) and the z coordinate always being 0. -- Thomas Broyer
[whatwg] createImageData should take unsigned long
As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. -- Philip Jägenstedt Opera Software
Re: [whatwg] Text areas with pattern attributes?
Mike Shaver wrote: It's also pretty common to enter multiple email addresses or tracking numbers or URLs one-per-line for batch operations on sites, and they would benefit from having client-side validation of such patterns. I also believe that it would be beneficial to have an option to regex-validate a text area in cases like this. One might argue that a case like this is served by having an AJAX interface with multiple inputs, but in my experience a lot of real world office work involves the worlds most used database, the spreadsheet. It's not far fetched to imagine copy-pasting a bunch of data from a spreadsheet column into a textarea, in which case it would make sense to be able to have client side validation for a given pattern repeated n times with newlines in between. I really don't see a case for not allowing pattern for a textarea. The implementation side should not be that different from the same attribute on a text input? Except for the client side overhead of parsing a large amount of data against a regex, what would be the drawbacks on having pattern on textareas? .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Global Script proposal
Patrick Mueller wrote:
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when
creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
Here's what Dmitry Titov proposed on 2009/08/17:
var context = new GlobalScript();
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Dmitry had a later note which combined creation of the context and
loading of the script. But I suspect one thing people will want to do,
in development anyway, is load multiple scripts into a context - like
you can in workers. Which would mean we'd still need a function to load
a script, or the only way to load a script would be by also creating a
new context - which is much like the serverJS module concept.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Comments on the definition of a valid e-mail address
On Mon, Aug 24, 2009 at 4:36 AM, Smylerssmyl...@stripey.com wrote: It's too complicated for most developers to roll their own validation, but there are standard libraries available which get it right. Standard libraries available for all major languages? As far as I can tell from a quick search, the PHP standard library contains no e-mail validation routines before 5.2.0 -- which isn't yet reliably available except to the small minority of website admins with root access to their machines. Moreover, the e-mail validation in 5.2.0 (filter_var()) seems to be wrong -- apparently it just uses, yes, a regex. (Don't use PHP is, obviously, not a useful response here.) If it were practical for everyone to validate strictly according to spec on both client and server side, that would be fine. I assume it was felt there was good reason not to do this in HTML 5. Forms on websites capturing users' e-mail addresses typically want just the address part, prompting for the human-readable name in a separate box, so I think HTML 5's input type=email not allowing the above is helpful. It might be more helpful if they stripped the part outside the angle brackets, but I agree that it's reasonable to just reject these. There may actually be several categories of oddly placed dots. While the address in the form you give above works it may be, say, that those with repeated dots in the hostname part don't work. On the specific case of a . immediately before the @, I've seen that before: this Perl library module extends an RFC-compliant module to allow just that; its author admits .@ breaks the RFCs but claims such breakage is useful in the real world, specifically when dealing with e-mail addresses for Japanese mobile phones: http://search.cpan.org/perldoc?Email::Valid::Loose That somebody has found this to be a sufficiently widespread problem with standard Perl e-mail address validation to write and upload a module which 'fixes' this (and just that; it makes no other changes) suggests that people will find HTML 5's input type=email to be problematic in precisely the same way. The breakdown of the 202 is as follows. * Single trailing dot in domain part: 100 (prohibited by RFC but plausibly deliverable) * Single trailing dot in local part: 40 (prohibited by RFC but plausibly deliverable) * Valid address in angle brackets (with other junk around it): 21 (permitted by RFC, kind of, and plausibly deliverable) * Multiple consecutive dots: 20 (prohibited by RFC but plausibly deliverable) * No @: 9 (unlikely to be deliverable) * Comment: 3 (permitted by RFC and plausibly deliverable) * Miscellaneous: 9 (one containing [...@[spam], two with trailing , one in quotes, one with single leading dot in local part, two with single leading comma in local part, one with leading : , one with leading \) Again, this excludes ~3000 that would be valid if [ \n\t] were stripped. Note that almost all of the hits seem like they probably are real working e-mail addresses that did have mail successfully sent to them (as opposed to a few that look like they were only confirmed by a bug). So it may actually be that there isn't a general problem here of lots of real-world e-mail addresses which work but don't comply with the RFCs; it may simply be the one case of .@? No, that was just the example I chose because I knew that person personally, and so was able to confirm that the address actually worked. I can't use my database access at Wikipedia to spam people just to see if their addresses work, so I can't confirm any of the others directly. Users often mis-type e-mail addresses. It seems useful to be able to trap as many typos as possible. Many authors obviously believe this, given how many employ JavaScript validators. If HTML 5 were overly permissive about input type=email then it's likely such authors would continue to use homegrown JavaScript solutions, which slightly defeats the purpose of HTML 5 introducing input type=email). I agree, but if the only purpose is to catch typos, it doesn't seem correct to completely prohibit submission. At most, you should warn the user. Of course, this would be potentially complicated to do.
Re: [whatwg] Comments on the definition of a valid e-mail address
On Mon, Aug 24, 2009 at 8:54 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: The breakdown of the 202 is as follows. * Single trailing dot in domain part: 100 (prohibited by RFC but plausibly deliverable) Do these still have a normal TLD identifier before the trailing dot? Or are they just *really* weird? I almost suspect that these are just simple typos that are cleaned up by mailers, and could be flagged as invalid. * Single trailing dot in local part: 40 (prohibited by RFC but plausibly deliverable) It seems that these are indeed valid in the wild, and so the algorithm should be loosened to allow these. * Valid address in angle brackets (with other junk around it): 21 (permitted by RFC, kind of, and plausibly deliverable) I'm fine with flagging these. The user can just remove the junk. * Multiple consecutive dots: 20 (prohibited by RFC but plausibly deliverable) We need to see if these are actually deliverable. * No @: 9 (unlikely to be deliverable) Flag them. * Comment: 3 (permitted by RFC and plausibly deliverable) What do you mean by this? Is it just fluff that doesn't affect the actual routing of the mail? If so, I'm fine with keeping them flagged, even if it is allowed by RFC. * Miscellaneous: 9 (one containing [...@[spam], two with trailing , one in quotes, one with single leading dot in local part, two with single leading comma in local part, one with leading : , one with leading \) It would be nice to see how many of the latter 6 are deliverable. ~TJ
Re: [whatwg] Comments on the definition of a valid e-mail address
Aryeh Gregor writes: On Mon, Aug 24, 2009 at 4:36 AM, Smylerssmyl...@stripey.com wrote: It's too complicated for most developers to roll their own validation, but there are standard libraries available which get it right. Standard libraries available for all major languages? I'd be surprised if they weren't. As far as I can tell from a quick search, the PHP standard library contains no e-mail validation routines before 5.2.0 Sorry, I meant there is a library (meaning additional to the core language) available in a standard place (wherever that language's libraries are typically found); I wasn't intending to claim that the standard library of functionality which is part of a language's core distribution would include it. For PHP I Googled email validation Pear and found the following as the top hit. I haven't tried it, but it claims to comply to RFC822, and I'd have more faith in it than the average home-rolled attempt: http://pear.php.net/package/Validate/ Forms on websites capturing users' e-mail addresses typically want just the address part, prompting for the human-readable name in a separate box, so I think HTML 5's input type=email not allowing the above is helpful. It might be more helpful if they stripped the part outside the angle brackets, but I agree that it's reasonable to just reject these. Good point. And that's largely a UI matter: either way the web server doesn't receive a value with the outside clutter in it. The breakdown of the 202 is as follows. Thanks for providing this. * Single trailing dot in domain part: 100 (prohibited by RFC but plausibly deliverable) Yup. If it is deliverable then surely it's an alias to the same address without the trailing dot, in which case a browser could choose to remove it. * Single trailing dot in local part: 40 (prohibited by RFC but plausibly deliverable) Discussed previously. This seems to be the problematic category. * Valid address in angle brackets (with other junk around it): 21 (permitted by RFC, kind of, and plausibly deliverable) Discussed above. * Multiple consecutive dots: 20 (prohibited by RFC but plausibly deliverable) If you mean the ..s are in the local part then yes, it sounds likely that would get delivered, and a quick non-exhaustive trial seemed to show this can work. (If they're in the hostname then I'd be amazed if it's deliverable, but surely it'd be to the same address that's reached by replacing sequences of dots to a single dot.) * No @: 9 (unlikely to be deliverable) Indeed. * Comment: 3 (permitted by RFC and plausibly deliverable) Equivalent to the angle bracket case above -- the address without the comment could be extracted. * Miscellaneous: 9 (one containing [...@[spam], two with trailing , one in quotes, one with single leading dot in local part, two with single leading comma in local part, one with leading : , one with leading \) They don't sound deliverable, or if they are would also be with superfluous punctuation stripped. And I'm not sure single cases are worth fretting about. If HTML 5 validation rejected one of the above it seems very likely the user would be able to provide an alternative address (or alternatively punctuated address) which is valid. So it may actually be that there isn't a general problem here of lots of real-world e-mail addresses which work but don't comply with the RFCs; it may simply be the one case of .@? No, that was just the example I chose because I knew that person personally, and so was able to confirm that the address actually worked. There are two categories of input which could be a working e-mail address yet violate the RFCs: 1 A valid e-mail address with extra 'stuff' in it or surrounding it (spaces, comments, trailing punctuation characters, etc). As you suggested, browsers can clean up the user's input, so what servers receive is a valid e-mail address. 2 A working e-mail address which contains something the RFCs say it shouldn't but needs that in order to function; attempting to clean it up would transform it to a different e-mail address, which possibly delivers somewhere differently from the original. Analysis of your detailed breakdown suggests the only addresses in category 2 are those with dots in odd places in the local part. So it may be the only change required to allow all working real-world e-mail addresses is a willful violation that permits dots anywhere in the local part (even immediately after another . or before the @). That change would appear to cover the cases in your data, but others may have data which shows there are additional cases. Smylers
Re: [whatwg] Orientation event in Firefox
Hi Doug, You are right, it is not specified yet anywhere, there is just an idea about it and we discussed in WebApps that we shall wait for feedback to my email. Having your feedback I have included the OrientationChangeEvent in the spec as a proposal. It is now available at http://dev.w3.org/2006/waf/widgets-vm/Overview.src.html#orientationchangeevent. It would be also good to have your opinion on splitting the ViewModes spec. BTW: I am still working on the ViewModes document, so some obvious bugs should be handled with patience :) Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Doug Turner [mailto:doug.tur...@gmail.com] Sent: Monday, August 24, 2009 4:25 PM To: Marcin Hanclik Cc: wha...@whatwg.org; public-device-a...@w3.org; public-weba...@w3.org Subject: Re: Orientation event in Firefox Hey Marcin, OrientationChangeEvent (as much as any name) sound fine, but I do not see what values you are passing into the event handler? The defition was not in [1] or [2] listed in your post, or in the mediafeatures.html attachment. What am I missing? Doug Turner On Aug 24, 2009, at 1:41 AM, Marcin Hanclik wrote: Hi Doug, What do you think about the proposal in [1]? Some discussion is needed on WebApps for this topic to move forward. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org ] On Behalf Of Doug Turner Sent: Monday, August 24, 2009 5:40 AM To: wha...@whatwg.org; public-device-a...@w3.org Subject: Orientation event in Firefox I posted some thoughts and a strawman for orientation in Firefox: http://dougt.org/wordpress/2009/08/orientation/ Regards, Doug Turner Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [whatwg] Text areas with pattern attributes?
Aryeh Gregor writes: On Wed, Aug 19, 2009 at 11:32 AM, Geoffrey Sneddongsned...@opera.com wrote: What's the use-case for it? Textareas are almost always for such large amounts of input that they are almost always free-form text. Why allow the pattern attribute? You could impose a minimum character length for posts -- that's common on forums. Or ban certain words or phrases. Are there currently sites using JavaScript to perform the above checks pre-submission? If so, would the checks be easier to write using a pattern attribute than they currently are? (If they aren't then it seems unlikely authors would bother with it.) Max Romantschuk writes: Mike Shaver wrote: It's also pretty common to enter multiple email addresses or tracking numbers or URLs one-per-line for batch operations on sites, and they would benefit from having client-side validation of such patterns. I also believe that it would be beneficial to have an option to regex-validate a text area in cases like this. It's not far fetched to imagine copy-pasting a bunch of data from a spreadsheet column into a textarea, in which case it would make sense to be able to have client side validation for a given pattern repeated n times with newlines in between. Are there any such sites already? If there aren't, it seems unlikely that the lack of textarea pattern=... is what's holding them back. I really don't see a case for not allowing pattern for a textarea. The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. Smylers
Re: [whatwg] Text areas with pattern attributes?
Smylers wrote: Are there currently sites using JavaScript to perform the above checks pre-submission? The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. It's been mentioned before about limiting the length of text permissible in a textarea element, specifically for forums. Part of my JavaScript library-ish thing makes this slightly easier for authors to use: http://performerjs.org/docs/limiter. I have no data about which sites the Performer script is used on, unfortunately. The other types of patterns I can imagine being used include text where newlines may be required at certain points for example CSV data, or lists that will be parsed into separate items server-side. Also a pattern to respond to certain words, for example qualifications (e.g. Doctorate or Degree). Also for spam checking, although as we all know too well it is almost impossible to completely stop the input of unwanted words. IRT also has a couple of script examples involving textareas, however these may be more complex than the spec pattern attribute can handle [1]. Chris [1] http://www.irt.org/script/1024.htm http://www.irt.org/script/1047.htm http://www.irt.org/script/690.htm This message has been scanned for malware by SurfControl plc. www.surfcontrol.com
Re: [whatwg] small element should allow nested elements
Alternatively, does anyone else think the small element should be capable of wrapping inline and block elements? (raises hand) I agree that allowing small to wrap inlines and blocks addresses Remy's use case directly and would allow authors to create other useful patterns for small print. Personally, I would like to see this change in the spec. I admit though, I am ignorant of the issues this has caused for the other elements Ian mentioned. I see that the content model of address has been redefined in HTML 5 to allow block elements. I'd like to see a similar change for small, but I ultimately defer to Ian to weigh the benefits against the cost in added complexity. I think changing the content model of small is more appropriate than changing its description. If the content model does not change, the description should not change either (since the description and content model work together to explain the appropriate use of the element). Chris -- Chris Cressman http://chriscressman.com
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor chris.tay...@figureout.comwrote: It's been mentioned before about limiting the length of text permissible in a textarea element, specifically for forums. textarea is defined to support maxlength already ( http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element ). I think pattern is significantly less valuable than maxlength, but it wouldn't be too difficult to add support for it. I vote weakly against. PK
Re: [whatwg] Text areas with pattern attributes?
2009/8/24 Peter Kasting pkast...@google.com: I think pattern is significantly less valuable than maxlength, but it wouldn't be too difficult to add support for it. I vote weakly against. More than that I'm a little concerned about potential performance drawbacks: having a pattern to be applied completely on a veeery long textarea could be a problem, such things can't be left to authors' good will. IMO. -- Bye, Michelangelo
Re: [whatwg] Global Script proposal
Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept. I think the plan is to provide an importScript(...) function to globalScripts as is done for workers... http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
Re: [whatwg] Global Script proposal
I did mention 2 forms of script load indeed, mostly trying to find a
simplest form that will be also consistent with what's already there in the
spec.
In terms of loading scripts, it seems the GlobalScript is quite similar to
what SharedWorker does to load its scripts.When creating SharedWorker, one
specifies the url right away as a constructor parameter, and this url later
is used to form an ID of the SharedWorker. The load is asynchronous and the
page is registering an event handler to 'hear' from the script when it is
ready. The Worker can, in turn, create 'nested' Workers (async). Also, it
can load more scripts into themselves via importScript(urls) - this time
synchronously (this is rough equivalent of script tag in a JS context).
Note that initial load is different from 'importing' more script - initial
loading is governed by SOP and is async, while the importScript can go
cross-domain, does not create a security context and is synchronous.
Whether or not this is the best possible scheme is a separate topic, but it
seems close enough to what GlobalScript needs so if nothing else,
consistency with this spec might be a good idea.
Dmitry
On Mon, Aug 24, 2009 at 6:05 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when
creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
Here's what Dmitry Titov proposed on 2009/08/17:
var context = new GlobalScript();
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Dmitry had a later note which combined creation of the context and loading
of the script. But I suspect one thing people will want to do, in
development anyway, is load multiple scripts into a context - like you can
in workers. Which would mean we'd still need a function to load a script,
or the only way to load a script would be by also creating a new context -
which is much like the serverJS module concept.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 6:04 AM, Max Romantschukm...@romantschuk.fi wrote: I really don't see a case for not allowing pattern for a textarea. The implementation side should not be that different from the same attribute on a text input? Except for the client side overhead of parsing a large amount of data against a regex, what would be the drawbacks on having pattern on textareas? Well, if the spec authors decide NOT to support the pattern attribute on text areas, I would ask the spec authors to insert a note (normative or not) explaining the rationale. Reason: I have this funny feeling I've asked about pattern attributes on text areas before. I think the question will be raised in the future. All of this has happened before, and it will happen again. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Comments on the definition of a valid e-mail address
On Mon, Aug 24, 2009 at 10:11 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: Do these still have a normal TLD identifier before the trailing dot? Or are they just *really* weird? None of the addresses had more than one thing wrong with it. These looked like perfectly normal addresses but with a trailing dot, like f...@example.com.. I assume mailers just drop the trailing dot here. example.com. is generally treated the same as example.com by everything except the actual DNS protocol, AFAIK -- if you resolve example.com the resolver will usually *append* the dot when it actually makes the query. It seems that these are indeed valid in the wild, and so the algorithm should be loosened to allow these. But the RFC forbids them. If we're going to even allow things that sort of work but which the RFC forbids, we may as well allow almost anything, because who knows if it might work on some software? We need to see if these are actually deliverable. I'd assume so. In theory all of these should be deliverable. The ones without @ obviously aren't, but those all look to have been confirmed back in 2006, so maybe there was a bug back then. Addresses with two or more consecutive dots have been confirmed as recently as May 2009. What do you mean by this? Is it just fluff that doesn't affect the actual routing of the mail? If so, I'm fine with keeping them flagged, even if it is allowed by RFC. I mean things like bobsm...@example.com (use for new groups only) If I'm reading the RFC correctly, the parenthesized part is a comment, and is ignored (like whitespace). On Mon, Aug 24, 2009 at 10:42 AM, Smylerssmyl...@stripey.com wrote: For PHP I Googled email validation Pear and found the following as the top hit. I haven't tried it, but it claims to comply to RFC822, and I'd have more faith in it than the average home-rolled attempt: http://pear.php.net/package/Validate/ I stand corrected, assuming that's usable for people with only FTP access. (It looks like it is, at a glance, since it's seemingly pure PHP.) Given this, I'm not clear why there's a need to deviate from the RFCs here. I assume the burden on UA implementors wouldn't be all that much. Granted, many web developers seem not to be using these validation libraries server-side, but I don't see how using different standards for input type=email helps that. Yup. If it is deliverable then surely it's an alias to the same address without the trailing dot, in which case a browser could choose to remove it. Yes, it's not possible for example.com. to mean anything different from example.com. (In fact they do mean something different in DNS, but example.com. means the same thing as what example.com is normally used to mean. Moreover, the meaning of example.com in DNS is basically nonsense for web apps processing user-submitted e-mail addresses. At least, as far as I understand it; I don't know too much about DNS.) Discussed previously. This seems to be the problematic category. I wouldn't rule out the existence of other problematic categories that happen not to have cropped up on the English Wikipedia. If you mean the ..s are in the local part then yes, it sounds likely that would get delivered, and a quick non-exhaustive trial seemed to show this can work. (If they're in the hostname then I'd be amazed if it's deliverable, but surely it'd be to the same address that's reached by replacing sequences of dots to a single dot.) Agreed. Of course, they're all in the local part. They don't sound deliverable, or if they are would also be with superfluous punctuation stripped. And I'm not sure single cases are worth fretting about. If HTML 5 validation rejected one of the above it seems very likely the user would be able to provide an alternative address (or alternatively punctuated address) which is valid. The one with a leading dot might be legitimate. I'd imagine the others are errors. There are two categories of input which could be a working e-mail address yet violate the RFCs: 1 A valid e-mail address with extra 'stuff' in it or surrounding it (spaces, comments, trailing punctuation characters, etc). As you suggested, browsers can clean up the user's input, so what servers receive is a valid e-mail address. 2 A working e-mail address which contains something the RFCs say it shouldn't but needs that in order to function; attempting to clean it up would transform it to a different e-mail address, which possibly delivers somewhere differently from the original. Analysis of your detailed breakdown suggests the only addresses in category 2 are those with dots in odd places in the local part. So it may be the only change required to allow all working real-world e-mail addresses is a willful violation that permits dots anywhere in the local part (even immediately after another . or before the @). That change would appear to cover the cases in your data, but others may
Re: [whatwg] Microdata
On Sat, 22 Aug 2009 23:51:48 +0200, Ian Hickson i...@hixie.ch wrote: Based on some of the feedback on Microdata recently, e.g.: http://www.jenitennison.com/blog/node/124 ...and a number of e-mails sent to this list and the W3C lists, I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand. If anyone has any concrete syntax ideas that they would like me to consider, please let me know. There's a (pretty low) limit to how many syntaxes we can perform usability tests on, though, so I won't be able to test every idea. I've found two related things that are a bit problematic. First, because itemprops are only associated with ancestor item elements or via the subject attribute, it's always necessary to find or create a separate element for the item. This leads to more convoluted markup for small items, so it would be nice if the first item and itemprop could be on the same element when it makes sense: p item=vevent itemprop=description Concert at span itemprop=dtstart19:00/span at span itemprop=locationthe beach/span. /p rather than p item=vevent span itemprop=description Concert at span itemprop=dtstart19:00/span at span itemprop=locationthe beach/span. /span /p Second, because composite items can only be made by adding item and itemprop to the same element, the embedded item has to know that it has a parent and what itemprop it should use to describe itself. James gave the example of something like planet where each article could be a com.example.blog item and within each article there could be any arbitrary author-supplied microdata [1]. I also feel that the item+itemprop syntax for composite items is one of the least intuitive parts of the current spec. It's easy to get confused about what the type of the item vs the itemprop should be and which item the itemprop actually belongs to. Given that flat items like vcard/vevent are likely to be the most common use case I think we should optimize for that. Child items can be created by using a predefined item property: itemprop=com.example.childtype item. The value of that property would then be the first item in tree-order (or all items in the subtree, not sure). This way, items would have better copy-paste resilience as the whole item element could be made into a top-level item simply by moving it, without meddling with the itemprop. If the parent-item (com.example.blog) doesn't know what the child-items are, it would simply use itemprop=item. Example: p item=vcard itemprop=n item My name is span itemprop=given-namePhilip/span span itemprop=family-nameJägenstedt/span. /p I'll admit that my examples are a bit simple, but the main point in my opinion is to make item+itemprop less confusing. There are basically only 3 options: 1. for compositing items (like now) 2. as shorthand on the top-level item (my suggestion) 3. disallow I'd primarily like for 1 and 2 to be tested, but 3 is a real option too. [1] http://krijnhoetmer.nl/irc-logs/whatwg/20090824#l-375 -- Philip Jägenstedt Opera Software
Re: [whatwg] Comments on the definition of a valid e-mail address
2009/8/24 Peter Kasting pkast...@google.com:
I am mentoring a student who is writing a patch for this in WebKit as we
speak -- we were just discussing the implementation yesterday and I believe
he hopes to have it out for review tomorrow.
The mentored student has published the patch and is waiting for
comments, however this is the pattern I've used:
dotAtomText = [a-z0-9!#$%'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%'*+/=?^_`{|}~-]+)*
Value is valid if matches entirely dotAtomText@dotAtomText. Every
feedback will be appreciated.
--
Bye,
Michelangelo
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 11:22 AM, Smylerssmyl...@stripey.com wrote:
Are there currently sites using JavaScript to perform the above checks
pre-submission?
There are many sites that use server-side checks for those purposes.
For instance, almost any site running the popular vBulletin forum
software imposes a minimum length on posts. I don't know if many
sites do client-side checks, but I'd imagine more would if it were
easier.
I should say that I can't see myself personally using pattern on textareas.
If so, would the checks be easier to write using a pattern attribute
than they currently are?
Yes. For instance, checking for a minimum length of 10 characters is
just pattern=.{10,}. Currently you'd have to do . . . I don't even
know offhand. My JavaScript isn't good enough. I'd have to spend
some time with online references to figure it out. Almost every web
developer is very familiar with regex; not every web developer knows
much JS. On the other hand, anyone who can write a JavaScript event
handler offhand can definitely handle pattern=.
I've recently been adding HTML 5 form features to MediaWiki, and found
that I was using features that I'd never have considered figuring out
the right JS for, because it was so simple. For instance, MediaWiki
currently uses JavaScript to autofocus forms on only a couple of
pages. When I saw that the autofocus attribute was available and
worked in a few significant browsers, I started adding it to every
single page where it made sense -- which means most form-based pages.
Also things like type=number that we just relied on server-side
validation for. Just because authors aren't currently going to the
trouble of writing JS doesn't mean they wouldn't use easier methods if
they were available.
On Mon, Aug 24, 2009 at 1:49 PM, Peter Kastingpkast...@google.com wrote:
On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor chris.tay...@figureout.com
wrote:
It's been mentioned before about limiting the length of text permissible
in a textarea element, specifically for forums.
textarea is defined to support maxlength already
( http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element ).
There's no minlength, though.
Re: [whatwg] Comments on the definition of a valid e-mail address
On Aug 24, 2009, at 3:24 PM, Aryeh Gregor wrote: Yup. If it is deliverable then surely it's an alias to the same address without the trailing dot, in which case a browser could choose to remove it. Yes, it's not possible for example.com. to mean anything different from example.com. (In fact they do mean something different in DNS, but example.com. means the same thing as what example.com is normally used to mean. Moreover, the meaning of example.com in DNS is basically nonsense for web apps processing user-submitted e-mail addresses. At least, as far as I understand it; I don't know too much about DNS.) Actually, the trailing dot is meaningful. A domain without a trailing dot is a relative domain; for example, if you are within the example.com domain, then foo could resolve to foo.example.com (or if that doesn't exist, then it would try resolving that at the root level, and fail since foo is not a TLD). A domain with a trailing dot is an absolute domain; it will only ever be resolved at the root level. This difference may be significant. If someone manages to register the top level domain mail (which may be possible if the proposed new gTLD rules are passed), and has an email address of f...@mail, then you might want to distinguish between that resolving to f...@mail.wikimedia.org vs. f...@mail. Of course, this is complicated because the trailing dot is technically not allowed in an email address, but it seems to work in some contexts that I've tried (though most just strip off the trailing dot). About the more general subject of this thread, I have tested sending myself email at all of the following addresses, all of which seem to work just fine, though some generate warnings in my mail client (Apple mail): Brian P. campb...@dartmouth.edu ...brian...p...campbell...@dartmouth.edu brian.p.campb...@dartmouth.edu. Brian (this is a test) P (of comments) Campbell (and whitespace)@(here comes the domain) dartmouth.edu brian p campbell Note that Dartmouth has a very permissive email system that allows name components to be delimited by whitespace and/or periods, and prefixes of name components as long as you wind up with a unique match. And of course the address without the domain only works when I'm sending within the same domain. In some cases, the addresses were altered slightly in the process of being sent, for example 'Brian P. campb...@dartmouth.edu ' came through as 'Brian P. Campbell@dartmouth.edu'. Given that there are so many technically invalid addresses that actually do work to deliver mail, and that I'm sure some people have odd addresses due to poor form validation (perhaps someone has signed up for an email account on a web form and it allowed spaces in the address), it's probably best to be relatively lenient about the addresses allowed. I think the best you can do is look for at least one character, followed by an @ sign, followed by a legal domain name (which seems to be more strictly checked, though given the presence of IDNs, may not be easy to restrict in the future as well). -- Brian
Re: [whatwg] Global Script proposal
BTW, the WorkerGlobalScope.importScript() API blocks the current thread of execution, which is probably not acceptable for code executed from page context. So for globalscripts we'll need some way to do async notifications when the loading is complete, and report errors. We may also want to have some way to automatically enforce ordering (so if I call GlobalScript.importScripts() twice in a row, the second script is not executed until after the first script is loaded/executed, to deal with dependencies between scripts). The alternative is to force applications to do their own manual ordering. -atw On Mon, Aug 24, 2009 at 11:32 AM, Michael Nordman micha...@google.comwrote: Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept. I think the plan is to provide an importScript(...) function to globalScripts as is done for workers... http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
Re: [whatwg] Microdata
On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
I've found two related things that are a bit problematic. First, because
itemprops are only associated with ancestor item elements or via the
subject attribute, it's always necessary to find or create a separate
element for the item. This leads to more convoluted markup for small
items, so it would be nice if the first item and itemprop could be on
the same element when it makes sense:
p item=vevent itemprop=description
Concert at span itemprop=dtstart19:00/span at span
itemprop=locationthe beach/span.
/p
rather than
p item=vevent
span itemprop=description
Concert at span itemprop=dtstart19:00/span at span
itemprop=locationthe beach/span.
/span
/p
As specced now, having itemprop= and item= on the same element implies
that the value of the property is an item rooted at this element.
Not supporting the above was intentional, to keep the mental model of the
markup very simple, rather than having shortcuts. (RDFa has lots of
shortcuts and it ended up being very difficult to keep the mental model
straight.)
Second, because composite items can only be made by adding item and
itemprop to the same element, the embedded item has to know that it has
a parent and what itemprop it should use to describe itself. James gave
the example of something like planet where each article could be a
com.example.blog item and within each article there could be any
arbitrary author-supplied microdata [1]. I also feel that the
item+itemprop syntax for composite items is one of the least intuitive
parts of the current spec. It's easy to get confused about what the type
of the item vs the itemprop should be and which item the itemprop
actually belongs to.
Fair points.
Given that flat items like vcard/vevent are likely to be the most common
use case I think we should optimize for that. Child items can be created
by using a predefined item property: itemprop=com.example.childtype
item.
Ok...
The value of that property would then be the first item in tree-order
(or all items in the subtree, not sure). This way, items would have
better copy-paste resilience as the whole item element could be made
into a top-level item simply by moving it, without meddling with the
itemprop.
That sounds kinda confusing...
If the parent-item (com.example.blog) doesn't know what the child-items
are, it would simply use itemprop=item.
I don't understand this at all.
Example:
p item=vcard itemprop=n item
My name is span itemprop=given-namePhilip/span
span itemprop=family-nameJägenstedt/span.
/p
I don't understand what this maps to at all.
I'll admit that my examples are a bit simple, but the main point in my
opinion is to make item+itemprop less confusing. There are basically
only 3 options:
1. for compositing items (like now)
2. as shorthand on the top-level item (my suggestion)
3. disallow
I'd primarily like for 1 and 2 to be tested, but 3 is a real option too.
[1] http://krijnhoetmer.nl/irc-logs/whatwg/20090824#l-375
We can't disallow nesting items as values of properties, there are a whole
bunch of use cases that depend on it.
Could you show how your syntax proposals would look when marking up the
following data?
// JSON DESCRIPTION OF MARKED UP DATA
// document URL: http://www.example.org/sample/test.html
{
items: [
{
type: com.example.product,
properties: {
about: [ http://example.com/products/bt200x; ],
image: [ http://www.example.org/sample/bt200x.jpeg; ] // please keep
this one outside the item in the DOM
name: [ GPS Receiver BT 200X ],
reldate: [ 2009-01-22 ],
review: [
{
type: ,
properties: {
reviewer: [ http://ln.hixie.ch/; ],
text: [ Lots of memory, not much battery, very little
accuracy. ]
}
}
],
}
},
{
type: work,
properties: {
about: [ http://www.example.org/sample/image.jpeg; ],
license: [ http://www.opensource.org/licenses/mit-license.php; ]
title: [ My Pond ],
}
}
]
}
Here's how it would be marked up today:
section id=bt200x item=com.example.product
link itemprop=about href=http://example.com/products/bt200x;
h1 itemprop=nameGPS Receiver BT 200X/h1
pRating: #x22C6;#x22C6;#x22C6;#x2729;#x2729; meta itemprop=rating
content=2/p
pRelease Date: time itemprop=reldate datetime=2009-01-22January
22/time/p
p itemprop=review itema itemprop=reviewer
href=http://ln.hixie.ch/;Ian/a:
span itemprop=textLots of memory, not much battery, very little
accuracy./span/p
/section
figure item=work
img itemprop=about src=image.jpeg
legend
pcite itemprop=titleMy Pond/cite/p
psmallLicensed under the a itemprop=license
href=http://www.opensource.org/licenses/mit-license.php;MIT
license/a./small
/legend
/figure
pimg subject=bt200x itemprop=image src
Re: [whatwg] Global Script proposal
Agreed, blocking semantics are definitely not OK for GlobalScript, this context-type calls for some form of async importScript functionality. If order load order matters, apps certainly could defer loading the scripts until what they depend on have been already loaded already. Where load order doesn't matter, seems unfortunate to penalize those callers. Maybe importScripts(['one.js', 'two.js'], onloadcallback, onerrorcallback); Immediately initiates in-order loading of the given array of resources. A second call to importScripts would also begin immediately as well. So if order matters, put them in the same importScripts call, and if it doesn't make individual calls. On Mon, Aug 24, 2009 at 3:15 PM, Drew Wilson atwil...@google.com wrote: BTW, the WorkerGlobalScope.importScript() API blocks the current thread of execution, which is probably not acceptable for code executed from page context. So for globalscripts we'll need some way to do async notifications when the loading is complete, and report errors. We may also want to have some way to automatically enforce ordering (so if I call GlobalScript.importScripts() twice in a row, the second script is not executed until after the first script is loaded/executed, to deal with dependencies between scripts). The alternative is to force applications to do their own manual ordering. -atw On Mon, Aug 24, 2009 at 11:32 AM, Michael Nordman micha...@google.comwrote: Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept. I think the plan is to provide an importScript(...) function to globalScripts as is done for workers... http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
Re: [whatwg] object behavior
On Fri, 14 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. OK, should the spec mention the change that Boris Zbarsky said had been made for Gecko? I guess this use makes up the majority of uses of object on the web (although the Content-Type header should be set to the same thing so it wouldn't normally matter). Presumably this would also change the rules for when to instantiate a new plugin, given that the current rules are essentially whenever a different plugin or data would be loaded. I'm not sure exactly what change you mean. The spec already has some of Gecko's behaviour (in particular the special-casing of certain MIME types to enable sniffing), are there other changes you think we should include? I'm also confused about the criteria for creating a nested browsing context. - If the resource type is an XML MIME type - If the resource type is HTML - If the resource type does not start with image/ Does that mean: - xml_mime_type OR html OR not_image this is the same as xml_mime_type OR not_image - xml_mime_type AND html AND not_image this would be application/xhtml+xml, application/ce-html+xml etc. but *not* text/html - (xml_mime_type OR html) AND not_image makes sense but would certainly need clarification in the spec The former. I've added an or and removed the (redundant) HTML line to make this clearer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Fri, 14 Aug 2009, Michael A. Puls II wrote:
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson i...@hixie.ch wrote:
- Should objects exist all the time whether they are attached to the
document or not?
Assuming you mean the plugins, as opposed to the elements themselves, then
the way the spec is written, the plugin instantiates regardless of whether
it is in the document or not.
Are you saying that in the following case (for the Netscape 6.4 WMP plug-in
(the liveconnect-supported one) for example):
script
var obj = document.createElement(object);
obj.setAttribute(type, application/x-mplayer2);
//document.documentElement.appendChild(obj);
window.onload = function() {
setTimeout(function() {
alert(obj.SetFileName);
//document.documentElement.removeChild(obj);
//alert(obj.SetFileName);
}, 1);
};
/script
that .SetFileName() (a function the plug-in supports), will be
accessible even if the object hasn't been attached yet? Are you also
saying that if it is attached and you remove it from the document that
SetFileName will still be callable?
Yes.
If so, that's not what happens in Opera. Pulling the object out of the
document nukes the plug-in instance and an instance isn't created until
you append to the document. Firefox behaves that way with plug-ins too.
And, I think that behavior is required for compat.
If it is required for compat, then we should change the spec. Can you
confirm that this is the case? Generally, having elements act different
out of document is something I'm trying to avoid.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Updated BWTP proposal
All, thanks for the useful feedback on the BWTP proposal. It was clear that while the features (such as meta-data and multi-plexing) were welcome, the proposal was perhaps too complex. I've written a second draft of the proposal http://bwtp.wikidot.com/main:proposal1 I have simplified this significantly by not using message headers to control the transport protocol, as that is mixing transport concerns with content concerns.Meta data is supported, but is not interpreted by the transport - only by the user agent and/or server. Thus multiplexing is now part of the protocol rather than a convention applied to URIs. There is explicit opening and closing of multiplexed channels that well maps to websocket onopen and onclose The result is more like a simplified BEEP than HTTP, but I still expect many parts of a HTTP implementation will be able to be reused. Note that the protocol can also carry HTTP traffic, so one connection can be used to carry HTTP and bidirectional traffic cheers
Re: [whatwg] Alt attribute for video and audio
On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: On Fri, Aug 14, 2009 at 9:13 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. For users who can use audio but not video, authors should either provide audio descriptions in the video file as alternative tracks, or supplemental material provided in links available to everyone near the video. For users who can use video but not audio, authors should provide subtitles, captions, or transcripts either in the video or audio file as supplemental tracks, or in supplemental materials available to everyone in links near the video. For users who can use neither video nor audio, supplemental materials are likely the best thing for an author to provide, again, in links visible to all. For users of legacy UAs that don't support these features, feature-rich alternatives such as plugins can be provided as fallback content for video and audio. Captions and subtitles can be included either directly in the media file, or scripts can manually support external resources using the cue range API. Going forward, we will probably also support dedicated formats that UAs can merge with the video to handle showing external subtitles natively. I don't see a need for an alt= attribute here. What problem would it solve that is not solved by the above solutions? There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. It seems that ARIA attributes, the title= attribute, figurelegend, and just regular UA defaults (e.g. announcing that you're on a video element) are sufficient. On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: On Fri, Aug 14, 2009 at 11:09 PM, Henri Sivonenhsivo...@iki.fi wrote: I believe aria-label addresses this. Excellent. Then I haven't seen a good argument to add it. Let's not. On Fri, 14 Aug 2009, Remco wrote: Yes, I think that covers it. This also covers the most important, but apparently always ignored case: authors who don't have time for accessibility. A significant portion of web authors will not provide subtitles for every published video. Nor will they provide links to a transcript. Even if they care about accessibility, it's just not economically viable to do it. The best you can hope for is a sentence or two explaining what the video does. This also covers other non-text elements: iframe, embed, object. The only thing left is ARIA's integration with HTML. Have you had success with your draft? http://hsivonen.iki.fi/aria-html5/ I see you only had one reply to your first announcement. Will the remaining ARIA attributes be an explicit part of HTML? Will the aria- prefix be removed? ARIA is now integrated in HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] small element should allow nested elements
On Fri, 14 Aug 2009, Aryeh Gregor wrote: On Fri, Aug 14, 2009 at 5:09 AM, Ian Hicksoni...@hixie.ch wrote: I wouldn't bother wrapping any of the above as small print. If you're structuring this enough that you have numbered lists and paragraphs and everything, then it's either not small print, or it shouldn't be. To the contrary: the more text there is, the more you want to make it small print. That's the point of small print. :) Even very brief legalese can often run to more than a paragraph. Even if it's not so useful for small or (say) em, it would make a lot of sense for various other elements that are currently only inline. For instance: strong: A particularly important section of a document. For instance, it's common in EULAs for one or two sections (like disclaimer of warranty) to be entirely uppercase, often running to multiple paragraphs. It would be semantically correct to wrap the entire section in strong. i: A run of text in a novel that's meant to be set off in mood from the surrounding text. For instance, a multiparagraph flashback sequence. cite: The name of a postmodern work of art whose author chose to name it something 7,000 words long. (Okay, I'm kidding.) I've run into more than one case where I wanted to wrap inline elements around blocks and couldn't. If this could be implemented in a reverse-compatible way, that would be awesome. We have done this with a, and the problems it introduces are substantial. I'm very reluctant to extend this to more elements. Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. I certainly realize that -- you can't even say what their CSS display property should be set to, at least not in a way that CSS currently supports. But once everyone has to support this behavior for those three elements, is there any reason not to extend the same behavior to other elements? Is there a significant marginal cost for allowing use as both inline and block for new elements once we've already paid the overhead of allowing it at all? Yes, I think so. You can special-case a few elements in an editor's UI, for example, without extending the complexity to the entire app. On Sat, 15 Aug 2009, Remy Sharp wrote: As Aryeh said, my experience has been the inverse, this is small print. I've got the terms and conditions for a competition, which is small print for the whole thing. Currently I'm manually wrapping every sentence in a small tag (as per my example). Just don't use small at all, and just make the font size smaller in CSS. For example, the BBC's web site is using the 62.5% rule, then by default pages are shown in 1.2em. The exception being their terms pages, which overrides the font size to 1em in a terms.css style sheet. This is because they want the text to appear as small print. BBC Terms: http://www.bbc.co.uk/terms/ That page is a great example of where _not_ to use small -- the text on there is the main content of the page, it's not a throw-away side comment. I've added text to this effect. Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. Is there any record of these issues. I know of 1 rendering issue that Firefox has with nesting the section element inside the a element (but I'm sure you're referring to previously solved issues). The issues are things like: * It makes it possible to have phrasing-level elements span paragraphs: Fred stood up. i How are you? p Are you ok? /i He sat down again. * It makes it very difficult to have intuitive UI in WYSIWYG editors. * It leads to confusing parsing behaviour, e.g. there are nested paragraphs here, which is not allowed, and is highly unobvious: p This is uncontroversial text. ins p This is new text. /ins del p This is deleted text. /del On Sat, 15 Aug 2009, Smylers wrote: Where small might be useful is another page which has a competition on it (in regular sized text) followed by: p smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;Cs./a./small /p In that case the short amount of 'small print' is distinguished from the surrounding text. Visual users can see it as such; a speaking browser could read it out faster. Right. On Sat, 15 Aug 2009, Remy Sharp wrote: Here's the actual example I'm working with: http://2009.full-frontal.org/ticket-draw (at the bottom of the page) You can see that I've had to wrap each inner li element, and also that the li bullet sizes don't match that of the text. It seems logical to me to wrap
Re: [whatwg] Textarea wrap=off
On Fri, 14 Aug 2009, Tab Atkins Jr. wrote: On Fri, Aug 14, 2009 at 4:22 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 7 Aug 2009, Tab Atkins Jr. wrote: Proposal Add the off state to the @wrap attribute for textareas. The off value is already defined in HTML5 for the purpose of rendering [1]. However, it isn't a conforming value, because it appears to have no purpose other than a visual presentational effect. [1] Last paragraph of: http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0 I can't load the full spec - it locks my browser - and I can't find any relevant text at http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-textarea-element. Is there some other place I should be looking in the multipage spec? If you just stick #the-textarea-element-0 on the end of any of the multipage spec's pages, it'll redirect you to the right place: On Fri, 14 Aug 2009, Anne van Kesteren wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-textarea-element-0 On Fri, 14 Aug 2009, Aryeh Gregor wrote: It's 11.4.15, Rendering, since it's a rendering hint and not a valid textarea attribute: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-textarea-element-0 Firefox doesn't seem to load the single-page version acceptably for me. Chrome is fairly slow -- especially if I accidentally do something that triggers reload of the page -- but mostly usable. If I want something that's really responsive, I resort to wget | less -- and searching through the whole text for a string once it's loaded into memory still takes a large fraction of a second. Works well in Safari, FWIW. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] type=email validation is too loose for practical applications
http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state A valid e-mail address is a string that matches the production dot-atom-text @ dot-atom-text where dot-atom-text is defined in RFC 5322 section 3.2.3. [RFC5322]http://www.whatwg.org/specs/web-apps/current-work/#refsRFC5322 I'd like stricter rule for it. e.g. dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT)) I understand the current production, dot-atom-text @ dot-atom-text, is a subset of addr-spec of RFC 5322. However dot-atom-text for the domain-part is not practical. The production accepts apparently unusable email address like tk...@ -- TAMURA Kent Software Engineer, Google
Re: [whatwg] .tags on HTMLCollections
On Fri, 14 Aug 2009, Jonas Sicking wrote: On Fri, Aug 14, 2009 at 3:35 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I haven't removed HTMLCollection.tags yet, since it appears to be implemented by most browsers. If we can get Opera and WebKit to remove support, then I'll remove it from the spec. Given that we have some data indicating that .tags() is not needed for web compatibility (Firefox doesn't support it and has received no requests for it, or bugs indicating sites needing it), and so far only weak data indicating it is needed (UAs support it, but not clear why), why not leave it out of the spec for now? UAs are always free to continue supporting it if they so please. I have very little desire to add support for anything to gecko just in case, without any data indicating anyone would use it, much less needs it. HTMLCollection.tags is specified for the same reason keygen is -- a majority of browsers support it. I'd like to remove it, though. I encourage you to convince other browser vendors to drop support for this feature. The difference is two-fold. First of all I thought we had indication that sites actually relied on keygen, i.e. we have some sort of data on that it's actually a used feature. Is that not the case? keygen is rarely used on the public Web. It's probably used less than .tags(), in fact, though I have no hard data to back this up. Second, .tags() arguably better belongs in a DOM-Core spec. So we could remove it for the same reason that HTML doesn't specify CSS quirks-mode behavior, that it's something better left to other specs. Why doesn't HTML for example define Element.children? That is also supported by a majority of other browsers (the exact same set of browsers even). I've (mostly arbitrarly) decided to leave features from the Element interface to Web DOM Core. HTMLCollection has HTML in the name, though, so it's harder to argue that it's out of scope! :-) But again, the choice there was mostly arbitrary. I needed HTMLCollection for a number of HTML features, and there was no spec that defined it. In general, I suspect if the only criteria to having something in the spec was supported by a majority of browsers and not currently defined by any other spec, then I strongly suspect the spec is missing a lot of features. Yes, it probably is. Feel free to raise issues for any that I've missed. Put it another way, what is the downside of removing it from the spec? The majority of browsers believe that it needs to be supported. Not defining it means that their implementations will not be tested as well, will be not quite the same, and so forth. The same disadvantages as not including pretty much _any_ feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing versioning from HTML
On Fri, 14 Aug 2009, João Eiras wrote: On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. The parts of the spec you would be implementing would still be stable, it's just that other parts of it would evolve. Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. We have to keep the spec from running away from implementations anyway, whether we have a stable snapshot model or a continually evolving model. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage. If we do snapshots, it just means the implementors are working on an obsolete version of the spec, which is worse. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] type=email validation is too loose for practical applications
On Mon, Aug 24, 2009 at 5:19 PM, TAMURA, Kent tk...@chromium.org wrote: http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state A valid e-mail address is a string that matches the production dot-atom-text @ dot-atom-text where dot-atom-text is defined in RFC 5322 section 3.2.3. [RFC5322]http://www.whatwg.org/specs/web-apps/current-work/#refsRFC5322 I'd like stricter rule for it. e.g. dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT)) I understand the current production, dot-atom-text @ dot-atom-text, is a subset of addr-spec of RFC 5322. However dot-atom-text for the domain-part is not practical. The production accepts apparently unusable email address like tk...@ It would have been nice to send this email as a reply to the current discussion about type=email validation (several messages sent earlier today), especially since the argument there is for _less_-strict validation. PK
Re: [whatwg] Comments on the definition of a valid e-mail address
FYI. I was in Gmail team and wrote the email address validation code which we are currently using. Gmail's validation rules are: - require @ - local-part should be - quoted-string without CFWS and FWS, or - 1*(atext / .)This means dot-atom-text without . restriction. This looseness was introduced for Japanese cell phone addresses. - domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+ It requires at least 1 dot. The last non-dot sequence should have at least 2 characters. I have never heard requests to support for non-ASCII characters other than IDN. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Comments on the definition of a valid e-mail address
- domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+ Correction. - is allowed for domain-part. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Sat, 15 Aug 2009, Elliotte Rusty Harold wrote: On Sat, Aug 15, 2009 at 4:40 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: This specification defines several comparison operators for strings. Really, operators? Is this the right word here? Maybe it should be several comparison operations on strings or several possible comparisons for strings. What's wrong with operators? They are literally functions that the rest of the spec uses, it seems like the right word here. A function is not an operator. According to Wikipedia, In mathematics, an operator is a function which operates on (or modifies) another function. A comparison is an operation on strings (data), not on other functions. In traditional programming languages such as Java and C, an operator is usually a language defined symbol, and occasionally a user defined symbol. That also doesn't apply here. For instance, in Java, operators are special symbols that perform specific operations on one, two, or three operands, and then return a result. What you're describing is likely a function or perhaps an operation, but I don't think it's an operator in the commonly understood senses of the term amongst the people likely to be reading this spec. I've removed the entire paragraph, to side-step this issue altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag and Drop Security Model and current implementations
On Sat, 15 Aug 2009, Aron Spohr wrote: during the dragover event: Full access to the dataTransfer object should be granted if the dragover event gets fired on a page with the exact same location as the location from where the dragstart event originated from. With location I mean at least full hostname and port (or default), not necessarily the protocol. This precise behaviour is currently implemented in Google Chrome 2.0.172.40 and Firefox 3.5, whereas Internet Explorer always grants full access regardless of different hostnames in the location between the originating dragstart and dragover events, so it would be compatible with this change. I believe this behaviour makes a lot of sense for a Web-Developer of a complex Web-Application which works over more than one browser-window as it would give him much more flexiblity on what can be done and previewed and decided on during a dragover operation before an actual drop event happens. Personally I'd guess the reason for this being implemented in Chrome and Firefox already is because their development-labs requested it. I've made the types list visible during all the events, but I'm skeptical about making everything available. We'll probably revisit this in a few years when we have a test suite for this. (I probably need to rewrite the way this section is written before making any more significant changes.) 2nd proposal during the dragover event: Access to the readonly attribute 'types' of the dataTransfer object should always be granted during a dragover event to allow the potential target element to response accordingly. The current spec doesn't allow a potential target element to decide during a dragover event based on the dragged data if it wants to accept a potential drop of that data or not. It always has to accept potential drops by preventing the default behaviour of the dragover event even if it can't process the data during a drop event. This can give the wrong indication to the user of the user agent if it turns out the element can't process the data when the drop event gets fired. Obviously it makes a lot of sense from a security perspective to restrict the access to the dataTransfer object during a potentially meaningless dragover event. However some indication on what type the data is should be given during the dragover event. The best compromise I believe would be to allow exclusive and read only access to the 'types' attribute of the dataTransfer object so that it can find out of what type the data is which can be potentially dropped upon it. All current implementations don't transfer any sensitive or confidential data in the types attribute. And obviously by definition of the current spec the 'types' attribute is not meant to be used for user data as it has to be used to specify the data types exlusively. Maybe to discourage abuse of the types attribute the length of each item should be limited as well as the characters it can hold. For instance I don't think it should accept any newline or linebreak characters. I've done this, though without the suggested restrictions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag and Drop Security Model and current implementations
I've made the types list visible during all the events, but I'm skeptical about making everything available. We'll probably revisit this in a few years when we have a test suite for this. (I probably need to rewrite the way this section is written before making any more significant changes.) I agree as I'm unsure what else *could* be safely exposed before the drop event -- realistically anything beyond the types seems risky: ignoring the obvious risks of exposing actual content, exposing any form of URI may lead to unintended information leaking (you have to assume that people are dragging random private files, urls, etc across windows and do not intend to drop them) --Oliver
