Re: [whatwg] Deferring image load
On Mon, 13 Feb 2012 12:11:21 +0100, Charles McCathieNevile wrote: On Mon, 13 Feb 2012 12:00:52 +0100, Kang-Hao (Kenny) Lu wrote: (12/02/13 18:33), Bjartur Thorlacius wrote: On 2/13/12, Gray Zhang wrote: 2. On an album page where hundreds of pictures are expected to be shown, it is often required that pictures currently in a user's screen should appear as fast as possible. Loading of a picture outside the screen can be deferred to the time that the picture enters or is about to enter the screen, for the purpose of optimization user experience. This seems like something interactive user agents should implement. But it is currently not reliable to the extent that Web authors can rely on it. The current spec for [1] says # User agents may obtain images immediately or on demand. Is there actually an existing user agent that obtain images on demand? Opera. Depends which product. Even Opera on desktop would previously try to be clever about what to load and not, however this caused much headache as authors expected all sorts of events and intrinsic dimensions just as if the resources were loaded and visible. For compat reasons Opera now is in line with other user agents. For compatibility it is better to have such mechanisms specced. -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] Browsers delay window.print() action until page load finishes
On Fri, 21 Jan 2011 00:51:41 +0100, Alexey Proskuryakov wrote: There seems to be no provision in the spec for a behavior Firefox and IE (and now WebKit-based browsers, too) have. If window.print() is called during page load, then its action is delayed until loading is finished. Opera is currently looking into a related issue. The issue we have is what to do with w = window.open(url) w.print() Right now Opera ignores print() here, but Yahoo!Mail depends on this for their printing functionality. The WebKit bug that changed this most recently is <https://bugs.webkit.org/show_bug.cgi?id=43658> - it has some information about trickier aspects of the behavior. This looks like something that needs to be formally specified. - WBR, Alexey Proskuryakov -- Ola P. Kleiven Core Compatibility PM Opera Software
Re: [whatwg] Form validation against invisible controls
On Wed, 04 Aug 2010 23:32:46 +0200, Ian Hickson wrote: On Fri, 4 Jun 2010, TAMURA, Kent wrote: > > > > An element is a "candidate for constraint validation" if > > 1. it is a validatable type, > >e.g. true if , false if > > 2. has no "disabled" attribute, > > 3. has no "readonly" attribute, > > 4. inside of a element, > > 5. has non-empty "name" attribute, and > > 6. not inside of a element. > > > > I hope ValidityState and the pseudo classes ignores 2-6. > > The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) The problem with that is that they still get submitted, so it seems weird to not validate them. It seems authors should be careful not to make the hidden controls be invalid. On Thu, 3 Jun 2010, Tab Atkins Jr. wrote: Adding @hidden to the list of things that skip validation is good. I considered it, but really we should also also stop submission in that case, and that seems like it's starting to make things a little less intuitive than I'd like. It's really up to the author to make sure that something that's irrelevant (hidden="") is not part of a form that is user-submittable. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. Indeed. On Fri, 4 Jun 2010, TAMURA, Kent wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation > > If one of the controls is not being rendered (e.g. it has the hidden > attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. I think, as the sentence above suggests, it's better to report this as a page error than to not validate the control. Chrome already reports this problem in the console. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. On Thu, 3 Jun 2010, Peter Kasting wrote: I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the "hidden" attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. Indeed. On Mon, 14 Jun 2010, TAMURA, Kent wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without "". Just don't autofill controls with invalid values, and don't autofill hidden controls. :-) On Mon, 14 Jun 2010, Ola P. Kleiven wrote: The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) site has now changed. barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) https://cart4.barnesandnoble.com/account/request.aspx?stage=mainStage - click "Create an Account". Will fail unless you fill in the fields in the form to the left (which is really unrelated) bookryanair.com (using required=false - this usage has also been found in JS libraries) site changed ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) https://www.ingdirect.com.au/client/index.aspx - type any "client number" and a 4 digit access code. Click log in. The client number field is then emptied by js before submitting but has required=true, causing error usairways.com (using required on hidden elements) The original issue seems to be gone (unable to search for flights from front page), but there is another one also related to WF2. Enter jfk in from o
Re: [whatwg] Constraint validation for maxlength
On Sat, 24 Jul 2010 00:21:10 +0200, Aryeh Gregor wrote: On Thu, Jul 22, 2010 at 5:46 PM, Jonas Sicking wrote: I think that depends largely on how many, and how big, sites are affected by this. Do you have a list of known sites with this issue? No, I was just raising the issue to see what people thought. Maybe someone from Opera could share a reason why they don't follow the spec here, unless the spec was different when they implemented it or something. From what I can see this was changed in Opera four years ago after some debate [1]. The big problem was pre- and script-filled fields that exceeded maxlength. Users got confused when fields they hadn't touched threw an error. See also [2] and [3] Sites that broke back then were: (I don't know know if any of them still are affected, many require login) The YaBB forum software SuperOffice eJournal (a support system Opera used) http://kayak.com/ (was fixed after we pointed it out) http://www.costco.com/ (internal navigation) http://www.nowwhere.com.au (zooming maps) http://www.zap2it.com http://www.kwick.de/forum 1) https://bugs.opera.com/browse/DSK-151609 (sorry, Opera access only) 2) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-February/005695.html 3) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-January/005459.html -- Ola P. Kleiven Core Compatibility PM Opera Software
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 07:41:40 +0200, Peter Kasting wrote: On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. How many existing sites? What sites are asking for form validation but then not actually working with it? If this isn't a large number, I would prefer to stay as-is and let the sites fix themselves. The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. We have also seen a couple of instances of wrong input types (number where text expected etc.), but the usage of "required" is the biggest problem in my experience. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without "". I think this is a mistake. PK -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] behavior
On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie wrote: On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson wrote: On Fri, 16 Oct 2009, Ben Laurie wrote: > On Thu, 6 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. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the "flash" to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. Perhaps I am failing to understand, but if I embed anything from an untrusted site, then it can choose what type it is - so how would I prevent it running Flash? Running Flash and allowing the same Flash to script your page are two different things. Flash needs allowscriptaccess="always" to script if it is loaded from a different domain. This may not be true for all plug-ins though. -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] behavior
On Mon, 31 Aug 2009 11:08:16 +0200, Ian Hickson wrote: On Tue, 25 Aug 2009, Andrew Oakley wrote: Ian Hickson wrote: > 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? Boris Zbarsky wrote (near the top of this thread): > If the type attribute was set to something that parsed as a MIME > type, and if that type would be handled by a plug-in (that is, we > have a plug-in to handle it, and have no other method for handling > it), then use the type attribute's type instead of the header type. So if we had a type attribute of application/x-shockwave-flash, and a Content-Type header of image/png we would use the flash plugin. Following the HTML5 spec we would use the image renderer. Ah, yes, that's intentional (doing otherwise violates HTTP1.1). Is this something you're forced into for compatibility? Opera prefers HTTP Content-Type over object type and we see some compatibility issues due to this. Examples that fail in Opera: http://www.antena3videos.com/ http://gamepod.hu/hir/ilyen_lett_a_terminator_salvation_es_a_bionic_comm.html -- Ola P. Kleiven, Core Compatibility, Opera Software
