Re: [whatwg] input type=barcode?
On Wed, 2011-08-03 at 17:21 +0200, Anne van Kesteren wrote: On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen mikko.rantalai...@peda.net wrote: What do you think? Implementing this seems rather complicated for such a niche use. It also seems better to let sites handle this by themselves so these physical codes can evolve more easily. I don't know how niche thing it is to actually own a dedicated USB barcode reader, but where I live, using at least one Web app that supports bar code reading (by having a text input requiring the bar code reader can emulate a keyboard) is as mainstream as Web app usage gets (banking). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 8/2/11, Ian Hickson i...@hixie.ch wrote: Unfortunately, as I said above... what we want and what we get don't always match. There's not much we can do here to push authors further. On the other hand, why accommodate the desires of authors? Why let authors decide whether I use gold on black or black on white? But I guess my concern is mainly an implementation issue at this point, as authors have assumed complete control over the rendering of their documents.
[whatwg] Bug in defineProperty
Hello,
It seems there is a bug in function Object.defineProperty.
When property was defined with enumerable descriptor = false, I can
anyway get it in iterator if was defined prop with the same name in
object prototype.
Almost all browsers affected , except for Firefox. Maybe this happened
due to ambiguous definition?
Test
function test() {Object.defineProperty(this, a, {value : b,
writable : true,
enumerable : false,
configurable : true});
}
test.prototype.a = c
t = new test()
for(x in t) console.log([x, t[x]])
Results
IE9: a,b
Chrome: a,b
Safari: not tested
Opera: failed
Firefox: nothing - right job
-Evgeny
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari eh...@mozilla.com wrote: On 11-08-03 4:13 PM, Aryeh Gregor wrote: Mike Smith has been kind enough to add a component to the W3C Bugzilla for the editing spec, in the WebApps WG product. From now on I'll use it for tracking feedback so I can be organized about things that I can't fix right away. The link to file a bug is: http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWGcomponent=HTML+Editing+APIs I'll still respond to all e-mail feedback. Is it possible to get a unique QA contact (or default CC address) for this component please, so that people who are interested in watching it can watch that email address instead of member-webapi-...@w3.org? Would this be possible, Mike?
Re: [whatwg] input type=barcode?
Henri Sivonen wrote: I don't know how niche thing it is to actually own a dedicated USB barcode reader, but where I live, using at least one Web app that supports bar code reading (by having a text input requiring the bar code reader can emulate a keyboard) is as mainstream as Web app usage gets (banking). Agreed, but barcodes are a technical aspect of input rather than data type comparable to type=email, type=url etc. As you say, when barcode input is an option, it's also an option to use normal keyboard input (though a browser could well use e.g. restricted on-screen keyboard if it knows what to expect). Moreover, the word barcode has multiple meanings. So I think that if the input of data commonly available as simple linear barcodes deserves a type of its own in HTML, it should be analyzed which logical data type would be involved. For example, the GTIN product codes (still often called EAN codes especially when in barcode format, or TUN or DUN codes) are in wide and increasing use and might be considered for inclusion. A browser could implement an input type for them using a barcode reader when available, otherwise using some method for input of digits together with checksum checking. This would be useful, though I don't know whether it's worth the specification and implementation effort (and things like this won't be really useful except after several years when all significant browsers have real support). Yucca
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Wed, Aug 3, 2011 at 1:13 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa rn...@webkit.org wrote: Feedback on selections 5 through 7: The definition of collapsed line break isn't clear. Maybe it's br immediately before the end of a block? Unfortunately, that's not good enough if we want it to be correct in all cases. For instance, the br in pspanbr!-- foo --/span/p behaves like a collapsed line break for CSS purposes. Maybe we could just let the algorithm be wrong in those cases, if we can't come up with a better definition. The problem is that a real definition would depend very heavily on CSS. This is why there's a big red box in the spec . . . I see. It's an interesting point. In WebKit, we're quite inconsistent in relying on CSS/rendering engine and pure DOM. This is an inherent issue in RTE because user would like the editor to work like WYSIWYG yet we have to produce conforming markup :( visibility: hidden shouldn't be taken into account, I don't think. Such nodes still take up space, they just don't get painted, so they don't behave like real invisible nodes. Right. But you definitely don't want to place a caret / selection end point inside a node with visibility : hidden. So to that extent, you'd have to mention it somewhere (definitely when you're normalizing selection end points). Step 3 in remove extraneous line breaks before seems redundant because we traverse the tree in the reversed tree order in step 4. I'm not sure what you mean. Step 3 is While ref has children, set ref to its lastChild, and step 4 is While ref is invisible but not an extraneous line break, and ref does not equal node's parent, set ref to the node before it in tree order. Ok. I misunderstood your algorithm then. To wrap a list node list of consecutive sibling nodes, run the following algorithm. In addition to node list, the algorithm accepts two inputs: an algorithm sibling criteria that accepts a node as input and outputs a boolean, and an algorithm new parent instructions that accepts nothing as input and outputs a node or null. If not provided, sibling criteria returns false and new parent instructions returns null. I also changed sibling criteria and new parent instructions to use var instead of dfn/span, to match other variables. Does that make it clear? http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2992f823 I still don't understand exactly when sibling criteria returns true and which node new parent instructors returns. Where are these algorithm defined? Also where would new parent be inserted if new parent's parent was not null? Or will it stay where it was? I clarified in a comment: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=5771e7c0 Does it make sense now? Yes! Thank you. Basically every time I add a br, it's because I found a case in tests where there was some bug otherwise. As far as I know, every time a br is added, it's needed to stop two lines from running together -- I avoid adding unnecessary brs and in fact remove them in a lot of places. If you look closely at the conditions, these br's will only be added when you're wrapping in block elements. Things like if you have blockquotefoo/blockquote[bar] and the author runs indent, it has to become blockquotefoobr[bar]/blockquote not blockquotefoo[bar]/blockquote None of these should normally do anything if you're wrapping in something like a b. Are there any specific cases that you think are unnecessary? Not really. Surprisingly or not, it's a very common technique used throughout WebKit's editing code. I just wished we could avoid adding br if we were to only remove them later. The biggest problem with phrasing content is that it's only defined for valid elements, but we need to also care about things like font for compatibility. I see. That's very unfortunate. Can we defined the list in terms of the phrasing content though? Or define phrasing content in terms of your definition? There's no interop on what backColor does, and I wound up defining it identically to hiliteColor. This basically matches the behavior of IE and WebKit, but Gecko and Opera behave differently. I personally think Gecko and Opera's behavior makes more sense here. I honor vertical-align because WebKit will currently create such markup in styleWithCSS = true mode, although the spec says not to, so I wanted the algorithm to handle the existing markup correctly. If WebKit wants to change, I'd be happy to remove this from the spec, since it complicates things. This is a WebKit bug that I've been intending to fix: https://bugs.webkit.org/show_bug.cgi?id=11089. This seems like it's the same basic idea as state override and value override. I clarified what those are meant to do, since it probably didn't make sense on a first reading: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=22697d3d
[whatwg] Script tags with src and content
I noticed that the html spec doesn't state what should be done with a
script tag with a non-empty src attribute *and* content inside.
Per section 4.3.1.3 [1] we just know that 'If a |script
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element|
element's |src
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-src|
attribute is specified, then the contents of the |script
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element|
element, if any, must correspond to putting the contents of the element
in JavaScript comments'
I think that such content would be ignored: since it has a src tag, it
would be marked as 'from an external file' and 'The contents of that
file are the script source', but it could also be considered to be
external and inline at the same time.
I realised this when looking at the recommended code for embedding
Google+ [2] (choose a language other than US English). It looks like
script type=text/javascript
src=https://apis.google.com/js/plusone.js;
{lang: 'en-GB'}
/script
The script [3] is too minified to follow, but it looks they are using
the same tag for including the script and embedding parameters, even
though they are disobeying a must by doing so. Maybe they have a string
reason and it's the spec what should allow such use. Either way, a
clarification in the specification looks good.
1-
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#inline-documentation-for-external-scripts
2- http://www.google.com/webmasters/+1/button/index.html
3- https://apis.google.com/js/plusone.js
Re: [whatwg] AppCache-related e-mails
On Tue, Aug 2, 2011 at 5:23 PM, Michael Nordman micha...@google.com wrote: On Mon, 13 Jun 2011, Michael Nordman wrote: Let's say there's a page in the cache to be used as a fallback resource, refers to the manifest by relative url... html manifest='x' Depending on the url that invokes the fallback resource, 'x' will be resolved to different absolute urls. When it doesn't match the actual manifest url, the fallback resource will get tagged as FOREIGN and will no longer be used to satisfy main resource loads. I'm not sure if this is a bug in chrome or a bug in the appcache spec just yet. I'm pretty certain that Safari will have the same behavior as chrome in this respect (the same bug). The value of the manifest attribute is interpreted as relative to the location of the loaded document in chrome and all webkit based browsers and that value is used to detect foreign'ness. The workaround/solution for this is to NOT put a manifest attribute in the html tag of the fallback resource (or to put either an absolute url or host relative url as the manifest attribute value). Or just make sure you always use relative URLs, even in the manifest. I don't really understand the problem here. Can you elaborate further? Suppose the fallback resource is setup like this... FALLBACK: / FallbackPage.html ... and that page contains a relative link to the manifest in its html tag like so... html manifest=file.manifest Any server request that fails under / will get FallbackPage.html in response. For example... /SomePage.html When the fallback is used in this case the manifest url will be interpreted as /file.manifest /Some/Other/Page.html And in this case the manifest url will be interpreted as /Some/Other/file.manifest On Fri, 1 Jul 2011, Michael Nordman wrote: Cross-origin resources listed in the CACHE section aren't retrieved with the 'Origin' header This is incorrect. They are fetched with the origin of the manifest. What makes you say no Origin header is included? I don't see mention of that in the draft? If that were the case then this wouldn't be an issue. I'm not familiar with CORS usage. Do xorigin subresource loads of all kinds (.js, .css, .png) carry the Origin header? I can imagine a server implementation that would examine the Origin header upfront, and if it didn't like what it saw, instead of computing the response without the origin listed in the Access-Control-Allow-Origin response header... it just wouldn't compute the response body and return an empty response without the origin listed in the Access-Control-Allow-Origin response header. If general subresource loads aren't sent with the Origin header, fetching all manifest listed resource with that header set could cause problems. According to some documentation over at mozilla'land, the value of the Origin header is different depending on the source of the request. https://wiki.mozilla.org/Security/Origin#When_Origin_is_served_.28and_when_it_is_.22null.22.29 So i think including Origin:manifestUrlOrigin when fetching all resources to populate an appcache could be the source of some subtle bugs.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
Here's my feedback on sections 1-3. I'll provide feedback on the rest of the specification in the near future. 3.2 * The gecko prefix should be changed to moz, to be compatible with other Gecko specific prefixes. * Do we have any other case where the HTML spec says that a browser can change its behavior if it's upgraded in the middle of the browsing session? 3.3 * Gecko currently has some problems in returning the correct status of a command based on the active range, so the results obtained from Firefox here should not be a determining factor (see https://bugzilla.mozilla.org/show_bug.cgi?id=676401). * On the same note, I actually think that WebKit's behavior makes sense. We need to make sure that _something_ happens when the command is executed after making sure that queryCommandEnabled returns true. If the beginning of the active range falls into an editable section, that would happen (perhaps to part of the range). Initially I thought that it would be better to return true if any range in the selection falls into the editable section, but that wouldn't make a lot of sense if the range spans across multiple contentEditable sections. Cheers, Ehsan
Re: [whatwg] Script tags with src and content
On Thu, Aug 4, 2011 at 3:32 PM, Den.Molib den.mo...@gmail.com wrote:
I noticed that the html spec doesn't state what should be done with a script
tag with a non-empty src attribute *and* content inside.
Yes it does. You ignore the contents, and only run the @src script.
Look at
http://www.whatwg.org/specs/web-apps/current-work/complete/scripting-1.html#execute-the-script-block
- step 2 - If the load was successful - step 1. The substep for
script was loaded from an external source comes before the script
was inline step.
I realised this when looking at the recommended code for embedding Google+
[2] (choose a language other than US English). It looks like
script type=text/javascript
src=https://apis.google.com/js/plusone.js;
{lang: 'en-GB'}
/script
The script [3] is too minified to follow, but it looks they are using the
same tag for including the script and embedding parameters, even though they
are disobeying a must by doing so. Maybe they have a string reason and it's
the spec what should allow such use. Either way, a clarification in the
specification looks good.
They're going against a must-level requirement, but the meaning is
easy - they're just using it the inline contents to store data that
the script will grab when it runs.
~TJ
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Wed, Aug 3, 2011 at 2:46 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com wrote: If they are identical I think it is even more clear we should remove the one on Document as it's redundant :-) Mn... but I think it's more convenient to be able to access undoManager from document. Also, what if there were no body? undoManager needs to exist in such cases as well (e.g. designMode). body is not the root element. And if there is no root element there is nothing visible on the screen so I am not sure it matters if things are lost in that case. That is such an edge case and not really worth having an additional member on Document for. Not sure. This happens all the time in design mode. We've had plenty of crash reports that only reproduce when there are no document element. It might also be hard to implement such a behavior in WebKit at least because documents / frames have the undo stack managed by OS X or embedders and having to fake non-existence of the undo stack might be tricky. - Ryosuke
Re: [whatwg] Discrepancies between HTML and ES rules for parsing an integer or float
On Wed, Aug 3, 2011 at 11:21 AM, Aryeh Gregor a...@aryeh.name wrote: Hixie just WONTFIXed two bugs that I thought might be of interest: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12220 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296 Basically, HTML defines some algorithms for parsing integers, floats, etc., which are used in converting DOM to IDL attributes for reflection (among other things): http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#numbers The algorithms for parsing integers and floats are almost exactly the same as ECMAScript's parseInt() and parseFloat(), down to some of the language being copied word-for-word, but with subtle differences involving (at least) whitespace handling. IMO, this is bad for several reasons: * It's confusing to both authors and implementers to have multiple almost identical algorithms. Nobody's going to expect the discrepancy in the corner cases where it matters. * It's confusing to people reading the spec for there to be these extra algorithms defined, whose relationship to the ES algorithms is not obvious. The HTML and ES algorithms are written in entirely different styles and it's hard to tell what the differences are from side-by-side inspections. * In at least some cases, all browsers match ES and none match the spec -- see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296#c4. * Browsers will have to maintain the ES algorithms as well as the HTML algorithms, so even if the HTML algorithms are superior, it doesn't save anyone the effort of understanding or implementing the ES algorithms. So I think HTML should just defer to ES here. Hixie disagrees, and has resolved both bugs twice now, so I'm not going to reopen them myself at this point. However, I'd like to hear from implementers whether they're willing to implement the spec as it stands, or whether they want the spec algorithms to be identical to ES's algorithms. It would make sense to me to match ES here. The main concern is of course website compat. Could someone detail what the differences would be compared to what implementations/the HTML5 spec do now? For parsing floats this would not seem like a problem though since attributes containing floats is relatively new IIRC. / Jonas
