[whatwg] Microdata feedback
On Wed, 13 Feb 2013, Ed Summers wrote: I am looking for some guidance about the use of multiple itemtypes in microdata [1], specifically the phrase defined to use the same vocabulary in: The item types must all be types defined in applicable specifications and must all be defined to use the same vocabulary. For example, does this mean that I can't say: div itemscope itemtype=http://acme.com/Foo http://zenith.com/Bar; ... /div It depends on what http://acme.com/Foo and http://zenith.com/Bar are. If they use the same vocabulary, then you can do it. If they're separate vocabularies, then no. The reason I ask is that there is some desire over in the schema.org community [2] to provide a mechanism for schema.org to be specialized. For example, in the case of an audiobook: div itemscope itemtype=http://schema.org/Book http://www.productontology.org/id/Audiobook; ... /div The idea being not to overload schema.org with more vocabulary, and to let vocabularies grow a bit more organically. If they're the same vocabulary -- that is, the properties on this .../Book vocabulary and this .../Audiobook vocabulary don't clash -- properties mean the same thing in both -- then it's fine. This schema.org group is currently thinking of using a one off property additionalType that would be used like so: div itemscope itemtype=http://schema.org/Book; link itemprop=additionalType href=http://www.productontology.org/id/Audiobook; ... /div I personally find this to be kind of distasteful since it replicates the mechanics that microdata's itemtype already offers. It's essentially equivalent, yes. So, my question: is it the case that itemtype cannot reference types in different vocabularies like the example above? If so, I'm curious to know what the rationale was, and if perhaps it could be relaxed. If they're different vocabularies (i.e. the same terms are used to mean different things), then you wouldn't know which was meant, so it would be ambiguous. There's an open bug about this topic with an open question: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13527 On Thu, 14 Feb 2013, Ed Summers wrote: In John's email [1] he proposed limiting multiple types to being from the same origin domain, not the same vocabulary as is stated in the Microdata spec. It sounds like an obvious question, but is there a precise definition of what is meant by same vocabulary? Or is it just a hand wavy way of talking about what humans understand when putting the itemtype URLs in their browsers, reading, and understanding that they are types that are part of some larger coherent whole? Vocabulary means the set of properties that are defined. There's some non-normative text in the HTML spec that talks about this: # The type gives the context for the properties, thus selecting a # vocabulary: a property named class given for an item with the type # http://census.example/person; might refer to the economic class of # an individual, while a property named class given for an item with # the type http://example.com/school/teacher; might refer to the # classroom a teacher has been assigned. Several types can share a # vocabulary. For example, the types # http://example.org/people/teacher; and # http://example.org/people/engineer; could be defined to use the # same vocabulary (though maybe some properties would not be # especially useful in both cases, e.g. maybe the # http://example.org/people/engineer; type might not typically be # used with the classroom property). Multiple types defined to use # the same vocabulary can be given for a single item by listing the # URLs as a space-separated list in the attribute' value. An item # cannot be given two types if they do not use the same vocabulary, # however. On Tue, 19 Feb 2013, Judson Lester wrote: There was an email from last year suggesting that the values of input elements be derived from their value attributes - the purpose there being to be able to control the form via the microdata interface. I've only been able to read it in the archives - the brief exchange was between Igor Nikolev and Ian Hickson, who was curious about use cases. Conversely, it would be useful to be able to use input elements to contain item values, and at the moment, since their values would be derived from their textContent, they're useless for that. Specifically, it's often reasonable to present a representation as the default values in a form and allow for updates simply by posting the changed values. It seems unwieldy to need to replicate that information in e.g. data elements. While it would be simple to treat the defaultValue as the item property value for elements (and for radio inputs, let the representation mark the selected input as the itemprop), it seems counter to the spirit of the proposal. The alternative would be to do something like excluding unsuccessful input elements during
Re: [whatwg] Should video controls generate click events?
On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
In a discussion about a click to play/pause feature for Opera on
Android, the issue of click event handlers came up.[1] The problem is
that pages can do things like this:
v.onclick = function() {
if (v.paused) {
v.play();
} else {
v.pause();
}
// no preventDefault()
}
I created a demo [2] and it is indeed the case that this makes video
controls unusable in both Presto and Chromium based browsers. Simon
Pieters has brought this up before, but the spec wasn't changed at that
point.[3]
While my demo may be on the hypothetical side, we do want users to be
able to bring up the native controls via a context menu and be able to
use them regardless of what the page does in its event handlers. So, I
request that the spec be explicit that interacting with the video
controls does not cause the normal script-visible events to be fired.
[1] https://codereview.chromium.org/17391015
[2] http://people.opera.com/~philipj/click.html
[3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/031916.html
(search for As with the post Simon cites above)
I've made the spec say this is a valid (and recommended) implemenation
strategy.
HTH,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness
all the data
in the first place, why not do it as part of the postMessage(), rather
than first building a binary data representation that you'll have to
reparse on the other side?
On Fri, 8 Mar 2013, David Rajchenbach-Teller wrote:
For instance, how would you serialize something as simple as the following?
{
name: The One,
hp: 1000,
achievements: [achiever, overachiever, extreme overachiever]
// Length of the list is unpredictable
}
Why serialise it? If you want to post this across a MessagePort to a
worker, or back from a worker, why not just post it?
var a = { ... }; // from above
port.postMessage(a);
What are the data you want to collect? Is it all at once or are you
building the object little by little? For a backup and for FirefoxOS
specifically, could a FileHandle [3] work? It's an async API to write
in a file.
Thanks for the suggestion. I am effectively working on refactoring
storing browser session data. Not for FirefoxOS, but for Firefox
Desktop, which gives me more architectural constraints but frees my hand
to extend the platform with additional non-web libraries.
Assuming by Firefox Desktop you mean the browser for desktop OSes called
Firefox, then, why not just do this in C++? I don't understand why you
would constrain yourself to using Web APIs in JavaScript to write a browser.
On Sat, 9 Mar 2013, David Bruant wrote:
I've once met someone who told me that JSON was bullshit. Since the guy had
blown my mind during a presentation, I've decided to give him a chance after
this sentence :-p He explained that in JSON, a lot of characters are double
quotes and commas and brackets. Also, you have to name fields.
He said that if you want to share 2 ints (like longitude and latitude), you
probably have to send the following down the wire:
'{long:12.986,lat: -98.047}'
which is about 30 bytes... for 2 numbers. He suggested that a client and
server could send only 2 floats (4 bytes each, so 8 bytes total) and have a
convention as to which number is first and you'd just be done with it.
30 bytes isn't fully fair because it could be gzipped, but that takes
additional processing time in both ends.
Hear hear.
He talked about a technology he was working on that, based on a message
description would output both the client and server code (in different
languages if necessary) so that whatever message you send, you just
write your business code and play with well-abstracted objects and the
generated code takes care of the annoying send/receive a well-
compressed message part.
This isn't a particularly new idea, FWIW. See, for example, protocol
buffers, or ASN.1's BER. Those are even self-describing to some extent,
like JSON; protocols like IP, TCP, and UDP don't even do that, they just
encode their data in a well-defined order with no delimiters at all.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] web messaging - postMessage
On Sun, 27 Jan 2013, Jack (Zhan, Hua Ping) wrote:
The postMessage design outlined in the W3C document edited by Ian
Hickson is not good! The design of the cross document messaging by Ian
Hickson (Google, Inc.) is very bad. Even the last version is not good
either.
:-(
The design can be sketched here as follows.
The sender:
var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
The receiver:
window.addEventListener('message', receiver, false);
function receiver(e) {
if (e.origin == 'http://example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello', e.origin);
} else {
alert(e.data);
}
}
}
This design was messed up by pulling origin (a word that some people
put too much attention more than should).
Can you elaborate on what you mean by pulling in this sentence?
Even worse, it requires o.contentWindow, this is really no
professional sense. Because of this design, if I open two tabs with the
same url http://www.google.com/ they are not able to communicate.
If you need to communicate between two otherwise unrelated tabs, there are
basically two solutions: a shared worker, or a broadcast mechanism. The
latter isn't currently specced, but discussion on how to do it is here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628
You can also currently fake this using the 'onstorage' event.
My better proposal
the sender:
window.postMessage(messageObject,targetDomain optional,windowIDs optional);
Either targetDomain or windowIDs should present.
I propose to use ID rather than name (though window can have a name),
since window.name is not required to be unique within the browser.
This is basically a broadcast mechanism, right.
One things that would be useful in making progress on this would be more
use cases, in particular use cases where it's important to be able to
respond after a broadcast.
There's basically only one use case in the bug above, namely informing
other windows of a state change (e.g. user logged in). This can currently
be done using onstorage and that could arguably in fact be a sufficient
solution (since for a change notification, there's no need to respond,
and it's typically stored state that has changed).
Cheers,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] XML data islands related question
On Thu, 7 Feb 2013, Neerja Anand wrote: Hello - it appears that XML data islands (originally created by Microsoft) have been discontinued in the newer browsers. We wanted to request they could be supported as an addon/plugin into the browser if not incorporated into the browser by default. We understand that this was a Microsoft only feature but they are extremely helpful to our business and their discontinuation would highly affect our business. Our request is to make them as an HTML5 standard, so all browsers would then have to support this feature. This would make the life of us developers much easier. We are not asking for Microsoft's version of XML data islands specifically, but would want this feature as a standard in some version. We noticed there is something new called Data Block which may be similar to XML data islands, but couldn't find much information on it to proceed. If you know of Data Blocks being an alternative to XML data islands, then if you could provide some documentation or point us to the location where we can get more information (with examples on how to use them) that would be very helpful as well. Could you elaborate on the use case? Why do you use them / want to use them? What are they for? On Thu, 7 Feb 2013, Mat Carey wrote: I'm not particularly active on WHATWG but the general approach seems to be that if you have a good idea you should go and create it, show that it works and then bring it to WHATWG for a wider adoption. That certainly is a solid way of approaching things. On Thu, 7 Feb 2013, Randy wrote: As far as I'm aware, Data Blocks should be or is part of HTML5. See https://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla for more info. On Thu, 7 Feb 2013, Jukka K. Korpela wrote: [...] browsers do not seem to support using a src attribute then; the non-script data must be inline, as element content, not fetched from an external source. I suppose the usual suspects (security considerations) are to be blaimed. This however means that the technique is not comparable to xml, which allowed external references. Right. It might be useful to mention explicitly in the spec that browsers do not generally allow non-script to be specified via the src attribute. The spec seems pretty clear about this: # When used to include data blocks (as opposed to scripts), the data must # be embedded inline, the format of the data must be given using the type # attribute, the src attribute must not be specified, and the contents of # the script element must conform to the requirements defined for the # format used. (This paragraph of script section.) And perhaps the spec should say that this is implementation-dependent and recommend that such references should be allowed, with due security considerations. Implementation-dependent behaviour is, on the whole, just a source of confusion for authors, so I'd rather not do that. You can just use XHR, instead. It's a bit odd that if you wish to set up a standalone application running in a browser (often called HTML5 application, without implying any particular version of HTML5), you can include e.g. scripts and images in separate files but not plain text or XML data Why can't you put plain text or XML data in other files? So long as everything is same origin, you can read anything you want via XHR. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] NoDatabase databases
columns. I think that in practice we're going to reach practical limits in user agents rendering tables long before we're going to reach practical limits of document size. A multimegabyte table is going to cause layout problems before it takes appreciable time to download. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Challenging canvas.supportsContext
On Fri, 2 Aug 2013, Benoit Jacob wrote: 2013/7/31 Ian Hickson i...@hixie.ch On Wed, 31 Jul 2013, Benoit Jacob wrote: Ping --- I thought that there was sufficient agreement in this thread, around the fact that supportsContext, as currently spec'd and currently implementable, is a feature without a valid use case, that removing it from the spec is the right thing to do at this point. It's on my list of e-mail to get to. Sorry about the delay. I'm currently about six months behind on feedback that isn't blocked on other things. In this particular case, I should note that we have at least one implementation, and we have no alternative solution to the problem for which the feature was added. So it's not as clear cut as it might seem. As discussed in this thread, the alternative solution is to call getContext and check if it succeeded That's not an alternative, that's the problem that this method was trying to fix in the first place. I was arguing that if one wants something reliable and tightly spec'd, there is no alternative to doing the same amount of work; and I was also arguing against the notion that something more loosely spec'd (as supportsContext currently is) was useful to have. Right -- that's why it's not clear cut. It's not just this is bad, we should drop it, or this is redundant, we should drop it, the questions are more subtle ones: is this problem worth solving, is the solution good enough, will it be implemented enough to be worth it, etc. I haven't studied the thread in enough detail yet to make an educated argument one way or the other. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)
On Sat, 3 Aug 2013, David Bruant wrote: Boris Zbarsky wrote: So his proposed implementation gives good defence in depth for things that are completely different origins and always will be, but does nothing for protecting mail.google.com from calendar.google.com, say, compared to the current situation.. And apparently @sandbox doesn't help here if there is allow-same-origin. So here is an idea: make the document.domain setter throw inside an iframe@sandbox, *regardless* of allow-same-origin. That solves the mail.google.com VS calendar.google.com case. How does it solve it? (What _is_ the mail.google.com vs calendar.google.com case?) It doesn't solve the case of when the parent shortens its document.domain to match the allow-same-origin sandboxed iframe, but I feel it's a rare case to load an x.y iframe from an w.x.y page. I think this is based on a misunderstanding of document.domain. For document.domain to work, _both_ sides have to do it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Parsing the string html
On Fri, 2 Aug 2013, Mohammad Al Houssami (Alumni) wrote: When parsing the string html the document should supposedly have an html root with head and body children. ( This is what live dom viewer shows at least) but according to the specs( if im not wrong) we only get the document with the html element and the stack of open elements will have html head and body elements in it. The html start tag token causes you to jump from the initial insertion mode to the before html insertion mode, and then the html element is created and you jump to before head. You then hit the end of file token, and that causes the head element to be generated, and switches you to in head, where head is popped and you switch to after head, where you insert a body element and switch to in body, at which point you stop parsing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Fri, 2 Aug 2013, Yasuhiko Minamide wrote: On Mon, 1 Jul 2013, Ian Hickson wrote: One option would be to remove from the stack of open elements any elements that we are skipping when we bail out of the AAA. Can anyone see a problem with doing that? I think that this solves the issue and clarifies the behaviour of the parser. The limits are really intended to reduce the memory consumption of the algorithm, not its running time. Elements are expensive, and this algorithm can create exponentially more elements than tags in the markup, when it's not limited. Although I agree with the revision above, I would like to clarify the behaviour of the AAA algorithm. I don't think that the AAA algorithm can create exponentially more elements even if it's not limited. Let D be the depth of the stack of open elements and S the size of the DOM tree that has been constructed so far. Then after application of the algorithm: * The size of the DOM tree is at most S + D. * The depth of the stack of open elements is at most D. Even if the algorithm is applied n times, the size of the DOM tree is bounded by S + nD. (not S * 2^n) In total, I think that the number of elements in the DOM tree is in O(m^2) where m is the number of tags in the source HTML. Yeah, that's more accurate. I should have said quadratically, not exponentially. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Parsing the string html
Ian wrote: On Fri, 2 Aug 2013, Mohammad Al Houssami (Alumni) wrote: When parsing the string html the document should supposedly have an html root with head and body children. ( This is what live dom viewer shows at least) but according to the specs( if im not wrong) we only get the document with the html element and the stack of open elements will have html head and body elements in it. The html start tag token causes you to jump from the initial insertion mode to the before html insertion mode, and then the html element is created and you jump to before head. You then hit the end of file token, and that causes the head element to be generated, and switches you to in head, where head is popped and you switch to after head, where you insert a body element and switch to in body, at which point you stop parsing. On Sat, 3 Aug 2013, Mohammad Al Houssami (Alumni) wrote: That is totally correct. But are the head and body elements added to the document? So basically when we stop parsing the document should only have the html element is that correct? On Fri, 2 Aug 2013, Tab Atkins Jr. wrote: No, the spec clearly says Insert an HTML element... for those as you trace through the parsing. As Tab says, when the elements are generated they are also immediately inserted into the document. For example, where it says: # Insert an HTML element for a body start tag token with no attributes. ...in the after head mode, Insert an HTML element is a hyperlink to the definition of that algorithm earlier in the spec, which says: # 1. Let the adjusted insertion location be the appropriate place for #inserting a node. ...which itself basically just boils down to inside current node, after its last child (if any), followed by: # 2. Create an element for the token in the HTML namespace, with the #intended parent being the element in which the adjusted insertion #location finds itself. ...followed by (skipping bits irrelevant to this case): # 4. If it is possible to insert an element at the adjusted insertion #location, then insert the newly created element at the adjusted #insertion location. ...which appends the body element to the html element (after the head element, which goes through the same process earlier). When you append a node to another, they end up in the same Document. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)
On Fri, 2 Aug 2013, Boris Zbarsky wrote: On 8/2/13 6:55 PM, Ian Hickson wrote: How does it solve it? (What _is_ the mail.google.com vs calendar.google.com case?) The case is when mail.google.com tries to attack calendar.google.com, and they can't be in different processes as mitigation because you never know when they'll both set domain to google.com... Ah, ok. It's clearer to describe that as the victim.example.com vs hostile.example.com case, since the fact that calendar.google.com redirects to www.google.com and mail.google.com doesn't is mostly just an accident of history at this point. Yes, the model I described in es-discuss doesn't attempt to mitigate that case. It groups similar-origin browsing contexts that share an event loop. It has the advantage (over models that do mitigate that specific case) that it happens to be compatible with the legacy security model (the one implemented, until recently, by all browsers); it has the disadvantage that near siblings, origin-wise, only have one level of protection against each other, not the full defense-in-depth. Honestly, though, at the point where you're able to trick a similar-origin site into changing document.domain so you can attack it, it's not clear to me that the extra level of defense is worth much. You can already, e.g., do XHR to the other origin, at that point, or read or write to its localStorage, or read its cookies, or send postMessage() with their origin credentials, or speak to their workers. I dunno, it seems like the fact that you can't get to objects in other iframes of that origin at that point is mostly moot. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Splash screen proposal for web apps ?
On Thu, 1 Aug 2013, Laurent Perez wrote: The use case is to show a please wait, loading... message until all resources of an index page (js, css, html, images, fonts) are downloaded. When the message dismisses, the index page is ready for a non-blocking UI navigation since js was already loaded. We plan to implement it in our own user agent, and I was wondering if I should go the Apple meta way or use the w3c widgets spec and use a webapp descriptor. I know the widgets spec has been implemented by some (Opera, Phonegap to describe an hybrid application), I was wondering if work was still going on on the splash proposal. Why not model applications around the same model as used by G+, where the splash is the application itself, just in a non-interactive state? If you can download the splash graphic, you can almost certainly download enough of the app to just show it. Basically, I think you should view as splash screens as much the same way as installation -- bugs from a legacy world that we should work hard to avoid reintroducing into the Web platform. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Namespaces and tag names in the HTML parser
On Wed, 10 Jul 2013, Peter Occil wrote: Short of explicitly putting in the HTML namespace at every occurrence of this, I don't know how to fix this. Putting in the HTML namespace everywhere is a non-starter, there's something like ten thousand occurrences of element names in the spec. (Literally. Ten thousand.) I don't mean in the entire HTML spec, I only mean within the tree construction section, and then only where it eliminates ambiguity, such as while the current node is not a tr element or an html element, as I stated previously. I agree it's silly to include the words in the HTML namespace everywhere in the spec. I don't really understand why that case is ambiguous, but thousands of others aren't. Can you elaborate on what the difference is? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Namespaces and tag names in the HTML parser
On Thu, 1 Aug 2013, Peter Occil wrote: Many of these cases occur in the normative portion of the tree construction stage. Most of them involve checking whether an element (as opposed to a tag token) has a certain name: Accordingly, these cases are ambiguous: [...] Thanks for listing these. As you can see, it's really only a few dozen ambiguous cases, not thousands. Why are the ones not in the parser part of the spec not ambiguous? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Namespaces and tag names in the HTML parser
On Thu, 1 Aug 2013, Peter Occil wrote: Sec. 12.2.4 (Tokenization) [...] I mean not in what is today section 12. For example, where the spec says Let the current column be the first col element child of the colgroup element. Why is that not ambiguous? Right at the top of the spec it says Except where otherwise stated, all elements defined or mentioned in this specification are in the HTML namespace (http://www.w3.org/1999/xhtml;), and all attributes defined or mentioned in this specification have no namespace.. What I'm confused about is why this is enough for part of the spec, but not other parts of the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Link element in body?
On Wed, 20 Mar 2013, Benjamin Stürmer wrote: I've been thinking about this exact thing for the last few weeks, because I have a use case in which it would be beneficial to use an in-body link to include CSS files, especially if link could be updated to support the scoped attribute with the same behavior as in style. My use case is a CMS in which editable content is loaded into an editor overlay via AJAX. This creates a bit of a nightmare due to the need to keep strict separation between rules that apply to page content and those that apply to the editor overlay, otherwise you end up with the editor overlay getting styled by rules meant for the content. I've solved the problem by introducing namespacing rules for CSS selectors, but a much more elegant solution would be to include CSS via scoped links. I don't think that FOUC in and of itself is a strong argument against allowing behavior like this. In my use case, FOUC wouldn't actually occur, and in any case I suspect that authors to whom issues like FOUC are important are aware of the significance of where they include their CSS in their documents, and authors to whom issues like FOUC aren't important aren't running their markup through validators in any case. This is on my radar, but note that in the meantime you can use: style@import my.css;/style At some point I plan to see how common it is for style elements to have @import rules; if it's common, then it would make sense to allow link in body for scoped style sheets as well. I hesitate to do it without a body of evidence showing it would be used a lot, because it's difficult to convey that link rel=stylesheet scoped href= would be allowed, while still having link rel=stylesheet href= and link rel=next href= non-conforming. I think authors would have more difficulty with the idea that certain rel= values are ok in certain places, than they would with the idea that certain attributes are ok there and others aren't. (With microdata, it's easier, because we just don't allow rel= at all.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scoped style sheets and @-rules
On Mon, 21 Jan 2013, L. David Baron wrote: I thought I'd brought this issue up before, but I can't seem to find a record of it. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped currently says that, inside scoped style sheets, @page rules are ignored, but other @-rules are honored, scoped either to the style sheet or to the subtree. I think it makes perfect sense to honor @-rules whose effects are scoped to the style sheet (@namespace, also @charset if it weren't already ignored) or @-rules whose effects are to condition the rules inside of them (all the rules in css3-conditional: @media, @supports) or import more rules (@import). But I think it's a large amount of extra implementation complexity to honor @-rules whose purpose is to build global dictionaries (in particular, @keyframes and @font-face), and I suspect the end result of honoring them would yield technology that's more confusing for authors. Anything that can be done by changing the meaning of an @keyframes or @font-face rule within a subtree could also be done by declaring a different animation rule or font-family within that subtree. I suspect the extra clarity from the latter makes it a better authoring practice anyway, so I don't think implementations should be required to add support for a feature that it's better to not use. Thus I think the specification should mandate that @keyframes and @font-face are ignored in scoped style sheets, just like @page. I think it would also be good if the specification left the effects of unknown @-rules undefined until whether they should be supported can be properly considered. I've deferred to the as-yet non-existent CSS Scoped Style Sheets specification on these matters. My concern with @font-face is that if we allow it and treat it as a global rule, it lets a scoped sheet mess around quite dramatically with the rest of the page, and if we disallow it, it prevents a pretty useful feature -- if people find type face control useful outside of scoped sheets, then why would they not want it just as much when syndicating the same content? Same with the @-rules for animation. Can we just not do good animations in scoped style sheets? Or indeed with components. Telling authors they can't do good typography with their components, or can't define keyframes for animation, etc, seems like a losing proposition. On Mon, 21 Jan 2013, Tab Atkins Jr. wrote: I think it makes sense to be able to create @keyframes and @font-face rules inside of a Component's style sheet, which is implicitly scoped, for example. Similar things (@counter-style, @text-transform, @image, other imaginary things with similar effect) also make sense in the same way. I would be concerned about namespace collisions. We've made that mistake with JS, where different libraries would stop on each other, to the point where we're now adding modules, and JS actually has scoping built-in, so it'd be even more dire with CSS, as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Namespaces and tag names in the HTML parser
On Thu, 1 Aug 2013, Peter Occil wrote:
- Let the current column be the first col element child of the colgroup
element is not considered ambiguous because the colgroup element
mentioned is understood to be the colgroup element in question (see
the beginning of the step: If the current element is a colgroup, follow
these substeps:). On the other hand, the phrase While the node is a
so-and-so element, etc. (and the patterns mentioned in my earlier
message) is ambiguous because it is not known beforehand what kind of
element is involved. (Also, ambiguity issues involving the first col
element child are moot because, as far as I can tell, an element named
col in a namespace other than HTML can't be a direct child of an HTML
colgroup element.)
Oh it's easy to end up with non-HTML elements in such places:
var cg = document.createElement('colgroup');
var c = document.createElementNS('http://example.com/', 'col');
cg.appendChild(c);
- The tree construction stage is more generic than other HTML algorithms
with respect to namespaces, while most of the rest of the spec deals
exclusively with the HTML namespace, making confusion much less likely.
I think it's a mistake to look at the spec this way. As shown above, it's
easy for non-HTML namespaces to end up in the middle of HTML elements, and
processing models have to take that into account. When the spec says the
first col element child, it has to be an HTML col element. Same in the
parser. There's no difference.
My main concern is that being triply-explicit (we're already doubly
explicit, given the text in the intro that says this, and the hyperlinks
from each occurrence of an element name in the parser to the element's
definition) will make people start wondering why we're explicit in some
places but not others, and they'll assume there's some meaningful
difference, and then they'll start making mistakes because of it.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] comments on 'position: absolute-anchored'
On Wed, 23 Jan 2013, L. David Baron wrote: A few comments on the 'position: absolute-anchored': http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#css-position-absolute-anchored (1) The interaction with CSS transforms is different from the interaction that 'position: fixed' has. Is that intentional? (Elements with a CSS transform establish a containing block for position:fixed elements.) If it is intentional, are implementors really ok with that (given the desire to be able to do things like animate transforms on another thread, and interactions with things like z-ordering rules)? The containing block is the ICB. Is that not sufficient to make this work? (2) I think it's unacceptable to have a computed value that's not specifiable in CSS; it breaks basic ideas of round-tripping and the CSS OM. I don't know how you could round-trip this. You have to call the method to make this work. CSSOM should be fine, though, the keyword is readable from there. (3) Is there a way to get notified when new CSS features are added to the HTML spec? I only happened to stumble across this one. Done (subscribe to the topic CSS). Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Challenging canvas.supportsContext
On Wed, 31 Jul 2013, Benoit Jacob wrote: Ping --- I thought that there was sufficient agreement in this thread, around the fact that supportsContext, as currently spec'd and currently implementable, is a feature without a valid use case, that removing it from the spec is the right thing to do at this point. It's on my list of e-mail to get to. Sorry about the delay. I'm currently about six months behind on feedback that isn't blocked on other things. In this particular case, I should note that we have at least one implementation, and we have no alternative solution to the problem for which the feature was added. So it's not as clear cut as it might seem. (Note that decisions for WHATWG specs aren't made based on consensus. Even if everyone agrees on something, if there's one more compelling argument to the contrary, that's the one that's going to win.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Entity definitions in XHTML
On Fri, 18 Jan 2013, David Carlisle wrote: On 17/01/2013 23:31, Ian Hickson wrote: On Thu, 17 Jan 2013, David Carlisle wrote: http://www.w3.org/2003/entities/2007doc/xhtmlpubid.html But basically it solves the problem that the existing list leads to a situation where data corruption and user confusion are both inevitable as the only way to enable entities to be loaded into a an xhtml agent is to reference a DTD that defines a different incompatible set of entities. This seems to be predicated on the assumption that the proposed new identifier would identify a different DTD than the existing identifiers. The proposed identifier _by definition_ identifies the list that is in the HTML spec. Not surprising since you extract the list from the same place. This is false. They would all identify the same DTD. No, they don't. That is the trouble. I think we're disagreeing about different things. If I understand correctly, you're saying that DTD A, in legacy UAs (XML processors implementing the DTDs as defined by XHTML 1.x specs and company), maps to different characters than you are proposing DTD B should map to in new UAs. I'm saying that in new UAs, those that implement the HTML spec, both A and B will map to the same set, because we've only got one set in the HTML spec. Only the proposed one identifies that list. The others are all pre-existing identifiers that identify incompatible sets. It is fine in a browser context that you over-ride that and load the HTML5 set in all cases but while you may control the browser you can't control existing workflows that already use these identifiers for the purposes for which they were defined, to identify the XHTML and MathML2 DTD. Browsers do not validate so can effectively use an implicit catalog that switches in the data URL with the HTML entities but since that contains no element definitions it would completely break any XML tools that rely on validation. The way the HTML spec is written, it does not override the XML spec. All it does is provide a catalogue that maps the following identifiers: -//W3C//DTD XHTML 1.0 Transitional//EN -//W3C//DTD XHTML 1.1//EN -//W3C//DTD XHTML 1.0 Strict//EN -//W3C//DTD XHTML 1.0 Frameset//EN -//W3C//DTD XHTML Basic 1.0//EN -//W3C//DTD XHTML 1.1 plus MathML 2.0//EN -//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN -//W3C//DTD MathML 2.0//EN -//WAPFORUM//DTD XHTML Mobile 1.0//EN Nothing stops a UA from supporting other DTDs, in particular system identifiers are still supporting as per the XML spec. If you specify a DTD that defines the HTML entity set, no entities are defined. If you specify a DTD which does not define them, they are all defined. This is so obviously sub-optimal I honestly can't understand how the bug can remain open for years after having been reported. The list is designed to make legacy XML documents keep working. If you think we should remove specific entries from this list, I'm happy to do so (but it'll cause pages to not work in browsers, since that's the only list they use). I see no value to adding to this list, since the list is purely for legacy purposes. The list in the spec was based on what browsers implemented. No. It is a subset of what mozilla did but bears no relation to what IE did for example. If it's a subset of what a browser did, then it was clearly based on what browsers implemented. As I note above there are many existing systems using the Public identifiers of XHTML1 to refer to the XHTML1 DTD and using validating parsers. They can not simply switch in a catalog that makes their existing document collections invalid. So they can not make documents using the XHTML1 public identifier load a DTD other than XHTML1 DTD. They don't need to implement the HTML spec either, right? I really don't understand the problem here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Splash screen proposal for web apps ?
On Wed, 31 Jul 2013, Laurent Perez wrote: Is there work going on on a Splash screen specification ? What's the use case? Generally speaking, Web pages load incrementally, so by the time you've downloaded an image, you should be able to just show the Web page itself, at least in a state good enough for the user. (For example, even really large and expensive pages like Google+ render in a usable state quickly, even though they continue to load assets and scripts in the background and thus actually don't present an interactive UI straight away.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Mon, 1 Jul 2013, Ian Hickson wrote: One option would be to remove from the stack of open elements any elements that we are skipping when we bail out of the AAA. Can anyone see a problem with doing that? Since nobody raised any problems with this, I've now done this. For background, this solves this case: divbisuttp/b123/p/tt/u/s456 Before this fix, the output is 456 123, with the 123 covered by s, u, tt, and b, and the 123 covered by b and i. After the fix, the output is 123 456, with the 123 covered by s, u, and b, and the 456 covered by no formatting elements. I could see an argument for leaving the elements in the list of formatting elements (so the output would be 123 456, with the 123 covered by s, u, and b, and the 456 covered by nothing, but with an i being reintroduced if you ended the whole thing with div789). Let me know if you think that's better. This being a change to the parser, it's risky; in fact it could change the styles of nodes. However, I think getting the output of the parser to be in the same order as the input is something that is far more important than getting the exact formatting styles correct. This is not just moving nodes out of a table; the old parser rules here moved nodes way off into earlier parts of the DOM with no intuitive logic. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Requiring the Encoding Standard preferred name is too strict for no good reason
On Mon, 1 Jul 2013, Glenn Maynard wrote: On Mon, Jul 1, 2013 at 6:16 PM, Ian Hickson i...@hixie.ch wrote: It seems bad, and maybe rather full of hubris, to make it conforming to use a label that we know will be interpreted in a manner that is a willful violation of its spec (that is, the ISO spec). It's hard enough to get people to label their encodings in the first place. It doesn't seem like a good idea to spend people's limited attention on encodings with you should change your encoding label, even though what you already have will always work, especially given how widespread the ISO-8859-1 label is. Fair enough. (FWIW, I wouldn't change a server to say windows-1252. The ISO spec is so far out of touch with reality that it's hard to consider it authoritative; in reality, ISO-8859-1 is 1252.) It certainly seems that that is how most software interprets it. On Tue, 2 Jul 2013, Jukka K. Korpela wrote: 2013-07-02 2:16, Ian Hickson wrote: The reason that ISO-8859-1 is currently non-conforming is that the label no longer means ISO-8859-1, as defined by the ISO. It actually means Windows-1252. Declaring ISO-8859-1 has no problems when the document does not contain bytes in the range 0x80...0x9F, as it should not. There is a huge number of existing pages to which this applies, and they are valid by HTML 4.01 (or, as the case may be, XHTML 1.0) rules. Declaring all of them as non-conforming and issuing an error message about them does not seem to be useful. Right. I note that you omitted to quote the following from my original e-mail: Previously, this was also somewhat the case, but it was only an error to use ISO-8859-1 in a manner that was not equivalent across both encodings (there was the concept of misinterpreted for compatibility). This was removed with the move to the Encoding spec. This kind of error handling is what I would personally prefer. You might say that such pages are risky and the risk should be announced, because if the page is later changed so that contains a byte in that range, it will not be interpreted by ISO-8859-1 but by windows-1252. Honestly merely not using UTF-8 is far more risky than the difference between 8859-1 and 1252. The encoding of the page is also the encoding used in a bunch of outgoing (encoding) features, and users aren't going to conveniently limit themselves to the character set of the encoding of the page when e.g. submitting forms. I think the simplest approach would be to declare U+0080...U+009F as forbidden in both serializations. I don't see any point in making them non-conforming in actual Win1252 content. That's not harmful. It seems bad, and maybe rather full of hubris, to make it conforming to use a label that we know will be interpreted in a manner that is a willful violation of its spec (that is, the ISO spec). In most cases, there is no violation of the ISO standard. Or, to put it in another way, taking ISO-8859-1 as a synonym for windows-1252 is fully compatible with the ISO 8859-1 standard as long as the document does not contain data that would be interpreted by ISO 8859-1 as C1 Controls (U+0080...U+009F), which it should not contain. It's still a violation. I'm not saying we shouldn't violate it; it's clearly the right thing to do. But despite having many willful violations of other standards in the HTML standard, I wouldn't want us to ever get to a stage where we were casual in our violations, or where we minimised or dismissed the issue. I would rather go back to having the conflicts be caught by validators than just throw the ISO spec under the bus, but it's really up to you (Henri, and whoever else is implementing a validator). Consider a typical case. Joe Q. Author is using ISO-8859-1 as he has done for years, and remains happy, until he tries to validate his page as HTML5. Is it useful that he gets an error message (and gets confused), even though his data is all ISO-8859-1 (without C1 Controls)? No, it's not. Like I said, I would rather go back to having the conflicts be caught by validators. Suppose then than he accidentally enters, say, the euro sign “€” because his text editor or other authoring tool lets him do – and stores it as windows-1252 encoded. Even then, no practical problem arises, due to the common error handling behavior, but at this point, it might be useful to give some diagnostic if the document is being validated. Right. Unfortunately it seems you and I are alone in thinking this. I would say that even then a warning about the problem would be sufficient, but it could be treated as an error There's not really a difference, in a validator. In any case, I've changed the spec to allow any label to be used for an encoding. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things
Re: [whatwg] Another issue in 12.2.5.5 parsing tokens in foreign content
On Thu, 4 Jul 2013, Michael Day wrote: The problem is that we can't do (2) in _all_ cases, e.g. innerHTML on an svg can't possibly break out of the svg if it sees one of these tags, since that's the root of what is being parsed. Yes, HTML has already lost the composability of parsing that XML and other languages have, that's long gone. But that doesn't mean we should try to make it even more irregular :) Currently Firefox, Chrome, and Prince all treat the fragment case the same as the whole document case, so we already have interoperable behaviour on this issue. If you treated them the same, you would either crash or have an infinite loop, because you'd either pop the root element off the stack and then try to append something to null, or you'd try to reprocess the token without having popped anything first. There has to be _some_ special casing of svg.innerHTML. What should the special casing be? Consider this case: svg.innerHTML = 'gp' I can see two possible options: svg | +-- g | +-- P Or: svg | +-- g | +-- P Neither are what happens in the non-fragment case (in that case the p is a sibling of the svg). Consider this case: svg.innerHTML = 'gsvggp' Here, the P node could be a child of the innermost g, the innermost svg, the outermost g, or the outermost svg. I could see arguments for all those cases. It seems unlikely that the author meant any of them. Since the HTML spec is supposed to reflect reality, it seems pointless to deliberately introduce an inconsistency in the parsing model that requires changes in all user agents to implement. All the user agents (or at least, all the browsers I could test) have to change anyway. Blink-based browsers and WebKit-based browsers don't support innerHTML on svg at all. Firefox supports innerHTML on svg but puts all the nodes in the HTML namespace. In conclusion, the reason I simply removed the quirk from fragment parsing rather than trying to make it work is that: - all browsers will have to change anyway, - the quirk needs special handling in the fragment case anyway, - it's not clear what the behaviour should be, - in many cases, we're not error-correcting in a useful way anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Requiring the Encoding Standard preferred name is too strict for no good reason
On Thu, 1 Aug 2013, Martin Janecke wrote: I don't see any sense in making a document that is declared as ISO-8859-1 and encoded as ISO-8859-1 non-conforming. Just because the ISO-8859-1 code points are a subset of windows-1252? So is US-ASCII. Should an US-ASCII declaration also be non-conforming then -- even if the document only contains bytes from the US-ASCII range? What's the benefit? I assume this is supposed to be helpful in some way, but to me it just seems wrong and confusing. If you avoid the bytes that are different in ISO-8859-1 and Win1252, the spec now allows you to use either label. (As well as cp1252, cp819, ibm819, l1, latin1, x-cp1252, etc.) The part that I find problematic is that if you use use byte 0x85 from Windows 1252 (U+2026 … HORIZONTAL ELLIPSIS), and then label the document as ansi_x3.4-1968, ascii, iso-8859-1, iso-ir-100, iso8859-1, iso_8859-1:1987, us-ascii, or a number of other options, it'll still be valid, and it'll work exactly as if you'd labeled it windows-1252. This despite the fact that in ASCII and in ISO-8859-1, byte 0x85 does not hap to U+2026. It maps to U+0085 in 8859-1, and it is undefined in ASCII (since ASCII is a 7 bit encoding). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier wrote:
On Mon, Jul 29, 2013 at 5:26 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 29 Jul 2013, Rik Cabanier wrote:
Does that mean it should be stroked along the path?
That depends on the platform. Some platforms render the focus as a
highlight, some as a dotted line around the exact path of the control,
some as a box around the bounding box of the focused control, etc.
The idea of this API is to let the user agent render the focus ring
however it is appropriate for the platform.
I see. So the user agent can decided if it closes the path, use end
caps, round joins, etc. Maybe the spec should be more specific and say
that nothing in the graphics state (except clipping) should affect the
focus ring.
Ok, done.
As for the color of the focus ring, shouldn't it come from the
':focus' style of the element that is passed in?
It should come from the platform.
Why not the style of the element? If the child element has a class of
'button' and the CSS has
button:focus {
color:red;
}
Shouldn't the focus be in red?
The button is likely to be invisible, so it's likely to not have computed
style, so I don't think this works.
On Mon, 29 Jul 2013, Dominic Mazzoni wrote:
While I also think there should probably be some way to override at
least the color of the focus ring in order to match the rest of the UI
Yeah, I think on the medium to long term we'll add something as suggested
in this e-mail:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Tue, 30 Jul 2013, Lara Rennie wrote: If they want a separate field, they can trivially just extract out the CEDEX bit by looking for the word CEDEX in the locality, and stripping it out if it's present. I would expect most implementations not to bother (since there doesn't seem to be any reason to -- just pretend the locality has CEDEX in the name, and it all works, no?). When you said you expect most implementations not to bother; this is not my experience at all. Any implementation that wants to find the address on the map would have to strip it out, and anyone who wants to do statistical analysis. Most implementations I've seen don't even offer the field. For example, I went to Amazon UK and tried to ship to a French address, and there was no mention of CEDEX anywhere. CEDEX is usually followed by a number - as per Address Doctor A CEDEX address is built of 5 characters followed by the locality name and the word CEDEX. This code can be followed by another identification number if there are more than one distribution points in one locality. If there is more than one arrondissement in one locality, the CEDEX code is followed by the one of the arrondissement. That just seems to make it even more part of the locality, to me. That is, the locality is either Paris or Paris CEDEX 04 or whatnot. Here's a random doc showing a CEDEX address: http://www.claudereichman.com/articles/Document%20CNAV0001.pdf The text-field is supposed to be filled in with the appropriate number. I agree this is not so intuitive for people who just want to say CEDEX without a number; maybe it should be a tick-box, and then once you've ticked it, you can optionally enter a number. I'm still thinking that this is rare enough that we shouldn't support it with its own dedicated field. In particular, since it's so rare that most people don't implement it, we'd have to come up with a way to split up the information when only one field was available, anyway. This just seems like a world of pain. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 parsing and specification challenges and difficulties
On Tue, 30 Jul 2013, Mohammad Al Houssami (Alumni) wrote: I am implementing an HTML5 parser and as part of the project I have to write a report that should include what are the major challenges faced during writing the specs of the parser and the actual parsing process. I have been trying to find some useful information but couldn't find any. Does anyone know if any references for what I want? The main challenge was that none of the browsers agreed, and so we had to first figure out what was actually necessary for compatibility with deployed content. After that, it was mostly just a lot of work, and then a lot more work cleaning up the edges. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input value sanitization algorithm
On Fri, 18 Jan 2013, Jonathan Watt wrote: In addition to the value sanitization algorithm, some input types specify actions that the user agent must take when the element's value is suffering from underflow/overflow or a step mismatch. To make it clearer that these actions will also be run when the value sanitization algorithm is run, could the text be changed to include each type's underflow/overflow and step mismatch actions under the the respective type's value sanitization algorithm? The steps that say to run when the element is suffering from a step mismatch run when the element is suffering from a step mismatch. It doesn't matter if it happens before or after the value sanitization algorithm, as far as I can tell. I don't really understand what's ambiguous here. (Otherwise it's unclear to me why some of the steps that are applied when converting the value content attribute to the input element's value have this special value sanitization algorithm label attached to them, while others do not.) The steps with the spec label attached are invoked by other algorithms (specifically, as you say, when the content attribute is changed, and also when the type attribute is changed, and when the element is created, and so forth.) The other algorithms are invoked when they say they are invoked, so they don't need a label -- nothing else directly invokes them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hide placeholder on input controls on focus
On Mon, 18 Mar 2013, Markus Ernst wrote: On several occasions I encountered that users got confused by the placeholders on input fields. In a doodle.com survey last week, 2 out of 5 people answered me via e-mail that they were not able to fill in their names in the name field, because they tried to highlight and delete the placeholder saying Your name. Also, some months ago I had phone calls from clients who were desperate because they thought they weren't able to log into their Hotmail accounts anymore, for the same reason (I think Hotmail has made the placeholder highlightable since then). It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible. This would be good feedback to provide to the browser vendors, so that they adjust their interface accordingly. Thus I'd suggest to modify the following sentence in 4.10.7.3.10: User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string or the control is not focused (or both), e.g. by displaying it inside a blank unfocused control and hiding it otherwise. To: ...when the element's value is the empty string _and_ the control is not focused, e.g. by displaying ... The idea is to allow multiple behaviours. The user agent is supposed to do what the user wants -- if a user wants a browser that shows the placeholder when they've focused the control and are staring at it trying to work out what to do next, then they should be allowed to have such a UA (at a minimum, by writing it themselves), without it being non-conforming. At the end of the day, there are valid arguments for both behaviours as well as many others (e.g. showing the placeholder in a bubble under the input control when you focus it, or having it slide to the right of the control when you click on it, or having the placeholder disappear when you click on the control and then reappear if you don't change anything, or having a separate part of the screen be a kind of running commentary of what's going on, and having the placeholder appear there when you hover over the control, or...). It's up to the UAs to pick the right behaviour for their users. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Defines the default size of input type='range' and other form controls
On Wed, 17 Apr 2013, Mounir Lamouri wrote: Currently the specification specifies some form control sizes (at least text controls and progress and meter elements) but most of the form controls bindings do not specify the expected default size of the control. I believe that the default size is quite important for interoperability, especially for inline-block elements that might end-up wrapped in text: if the default height is defined in px or em, the rendering might differ a lot. I think that it would be great to define default sizes for form controls, in em preferably I guess. I'd been intentionally not specifying this so as to not bias implementations, and so as to see what implementations settled upon. If implementations are ready to freeze their current behaviours, I'm happy to start adding this kind of detail to the spec. Has this time come? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Ignore min and max if min max
On Wed, 17 Apr 2013, Mounir Lamouri wrote: Currently, the specification seems to take care of min max by simply making the element suffering from a value underflow such as a value overflow. Also, input type='range' has a special behaviour in that situation. However, if you try different implementations, the behaviours when min max a widely different and generally speaking, such context can create pretty broken UI: a slider that can't move, a number spinner that doesn't allow changing the number's value, etc. I believe that having a special behaviour when min max would be appropriate here. Basically, the min and max attributes should be ignored in that situation. That means that the element's 'minimum' and 'maximum' should be ignored in that situation unless there is a 'default minimum' or a 'default maximum' (which would be used). Adding this to the specification would help having a decent fallback when the attributes are broken instead of broken form controls. FWIW, Chrome's implementation of input type='range' seems to simply ignore min and max when min max. Opera doesn't show any UI in that case. Generally speaking, we define the behaviour when the markup is bogus, but we don't go out of our way to make it useful, for two main reasons: first, it's hard to tell what is useful when the information we have is known to be wrong (did they get them backwards? Did they omit a digit in the max value? Did they put the decimal in the wrong place on the min value?), and two, by having useful behaviour we make it much less likely that errors will be caught (it's easier to catch a bug if users can't enter any valid data at all, than it is if the error checking is just disabled). Are we sure we really want to go down this path? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
if they are using the (open-sourced) Google Address Widget? Good point. I know Google forms use it extensively and others can too. I don't think it's currently marked with autocomplete attributes, but it would be great if it were. I just tried the Google address widget, and I have to be honest, I don't understand the way it uses the CEDEX field. It seems to be a free-form text field, which makes no sense to me. Are we sure people in locales that use CEDEX won't find it more intuitive to add it after the locality, the way it is written on envelopes? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier wrote: The idea is it's supposed to be the system style (hence the name of the method, draw _system_ focus ring), and that if the authors wants a special style, they use drawCustomFocusRing() and if it returns true they draw it themselves (using strokeStyle and stroke(), or whatever). There's an example in the spec -- search for couple of checkboxes. That example doesn't show how the focus rings are supposed to render. The spec says: ... draws a focus ring *around *the current default path or the given path ... Note that that text is non-normative. There's a big box to that effect just above the text itself. and: ... draw a focus ring of the appropriate style along the intended path... That one is normative. Which way should it be drawn? The way the normative one says it is to be drawn. It seems that the focus ring should be around the path and drawn in accordance to the browser's algorithm of focus regions. Not really should what you're asking. Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Mon, 14 Jan 2013, Jonas Sicking wrote: On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Nov 2012, Mikko Rantalainen wrote: Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki): On Wed, 21 Nov 2012, Mounir Lamouri wrote: Then, maybe a better naming could be datetime-utc? I think that would mislead authors into thinking that the UI that users will see is one that asks for a UTC time. That kind of UI is the worst UI for this kind of feature, so that would be misleading. I'd suggest datetime-absolute because the other variant is floating or relative (to local politically decided time which may vary depending on future political decisions). We could rename datetime to datetime-absolute and leave datetime-local as named, but I'm not really convinced that's much better than what we have now. I think it more common for people to interact mainly with people in their own timezone. I.e. most time when talking about dates and times people don't mention what timezone is involved and rely on context to provide that information. I agree that that is accurate for when people talk. But that's somewhat misleading, I think, regarding what it implies about form controls. In Web apps, there's basically three cases: 1. Cases where you mean a specific global time (a time relative to UTC), for coordination amongst people from many locations. For example: the time that a broadcast begins e.g. a live Hangout on G+ the time that a deliverable is due e.g. the due date for a poetry contest the time that a resource becomes available and the time it stops being available, if scheduled in advance e.g. the time that a meeting phone bridge code starts working and the time it ends working 2. Cases where you mean a specific global time (a time relative to UTC), but where the time is really only relevant for local purposes, and so when given is likely to be given relative to an implied time zone. For example: the time that a plane takes off or lands the time that a physical meeting (not one involving video conferencing across multiple sites) begins the time that someone wants to go home from work 3. Cases where you mean a floating time and no time zone actually applies. For example: a wake-up alarm on a phone (wake me up at 8am on Monday, where the time zone isn't decided until Monday, by examining where the user is) the time for an event celebrated at different times in different time zones, e.g. New Year's. Now, when implementing these, there's often mistakes made. For example, authors will often confuse case 1 for case 2, and will often confuse case 2 for case 3. That is, they will often assume a time zone when one should not be assumed, and will often forget about time zones entirely when a time zone should be assumed. For example, they may ask for the time that a broadcast begins, and then just assume that the time zone is the time zone of the server. This would work fine in a single-time-zone-company where the server is colocated with the users. Similarly, they might ask for the time of a plane's departure, and then display it in the user's time zone, forgetting that there's an implied time zone given by the user's location. The opposite error is harder to make. It's harder to ignore the time zone when all times that the user enters get converted to UTC -- unless you're in the UK during the winter, or one of a handful of other countries using UTC, you're likely to notice right away (and even in those, in many cases you'll likely notice within 6 months). Because of this likelihood for mistakes, the controls are designed so that forgetting a time zone requires more characters than giving one. Authors are less likely to initially use datetime-local than datetime, so they're more likely to be reminded to use time zones immediately, than they are to forget to use time zones until too late. So in most contexts when people think about a point in time, they do so for a specific timezone. I don't know how to evaluate if this is true. When that is not the case, this is something that people are aware of. When I interact with friends/family/coworkers where the timezone is not obvious this is quite clear. And in these cases I'm aware that I need to specify timezone. I don't know that that's the case. I think it's more likely that authors will incorrectly forget to use time zones when they should have, than it is for them to use time zones when they should not. That, as described above, is the principle on which the spec's design was based. So I would imagine that when a developer sees datetime that does
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier wrote: Does that mean it should be stroked along the path? That depends on the platform. Some platforms render the focus as a highlight, some as a dotted line around the exact path of the control, some as a box around the bounding box of the focused control, etc. The idea of this API is to let the user agent render the focus ring however it is appropriate for the platform. How is the focus ring usually calculated? Does the UA know about the shape of the focused objects and then draws a box around it? It depends on the platform. As for the color of the focus ring, shouldn't it come from the ':focus' style of the element that is passed in? It should come from the platform. See also this recent discussion: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Mon, 29 Jul 2013, Jonas Sicking wrote: Ian, has *any* implementer expressed a preference for implementing a picker which allows selecting date+time+timezone? I.e. one that returns UTC dates? Your i.e. is a non-sequitur. A control that has date+time+timezone in the UI and a control that always returns UTC dates are orthogonal descriptions. type=datetime is not a control that allows selecting date+time+timezone. Regarding whether implementors have expressed interest in implementing specific controls: the controls currently in the spec were based on use cases, not on what specific implementors had indicated in terms of implementation interest. Once you can implement type=datetime-local, pretty much all the other date-related controls are trivial to implement usefully. I have seen plenty of date and time pickers. But never one that also allowed the user to set the timezone as part of the same widget. I have seen some, but that's academic, since none of the input controls in the HTML spec today are such a control. I.e. claiming that there is *far* more widgets elsewhere which separates picking date/times from ones that are picking date/time/timezones. Are you really claiming that this is not the case? This seems like a claim that needs to be backed up in some form. As noted in my previous e-mail, I'm not making any claims as to the relative proportions of the various controls. The design in the spec isn't about that, it's about reducing authoring mistakes by exposing authors to bugs quicker. Additionally, if we were to build a date+time+timezone picker, the current API to such a picker is insufficient since a date/time expressed in UTC is insufficient to express a date+time+timezone. Agreed. I don't think anyone is suggesting building such a picker at this time. I could definitely see a need for it -- or more likely, for specifically a time-zone picker -- but it's a much harder problem than the existing controls, as noted in my previous e-mail on this thread. If we want to return UTC dates, I instead propose that we make the element take a timezone as an input (through an attribute or some such). The picker would then select just date+time but return a result using UTC timezone. I don't understand the use case for such a control. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. That's type=datetime (the time zone is always UTC). In contrast, when the app doesn't want a timezone, the developer should probably use something like datetime-floating. Then, it's clear that the time zone is actually left off of the returned value, too. That's type=datetime-local. It's not only useful for floating times, as noted in the response on this bug, which is why it's not called something with floating in the name: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17856 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Session history and discarding of Documents
On Mon, 29 Jul 2013, Andrew Oakley wrote: As far as I can tell when the user agent discards a Document in the session history may change the contents of the history. This seems wrong to me because it makes non-deterministic visible to scripting. The scenario that I'm thinking of is: index has a frame that is navigated to: container which has a frame that is navigated to: page1 (default using src=page1) page2 The joint session history now contains (elements in parenthesis are removed because they are current entries in their respective session histories): (index) (container) page1 page2 If container is now navigated to empty we get this: (index) container empty Now if we go back() and the Document for container has not been discarded and therefore the nested browsing context exists we get page2 visible in the frame and this joint session history: (index) (container) page1 page2 empty If the Document for container had been discarded then the nested browsing context and it's session history is discarded. This means that page1 is visible in the frame and we get this joint session history: (index) (container) page1 empty Apologies if the above description is confusing, it's rather difficult to describe. I have not managed to find a way to get desktop browsers to actually discard the Document for container, I'm guessing there is some sort of heuristic based on memory available. In a memory-constrained environment a browser may wish to destroy the Document's fairly quickly and I expect to see the second behaviour. Have I missed something or misunderstood the spec here? As far as I can tell there is actually no requirement to maintain session history for any nested browsing context that belongs to a document which is not active but the major browser do. I believe your description is correct. There's not much we can do about it. We can't require that UAs remember everything, since on some devices (e.g. mobile phones) even the browser itself might get discarded if the user even so much as glances away. We can't require that the UAs forget everything as soon as possible, because remembering things is viewed as a massive performance benefit by some browser vendors, and they won't stop doing it, since they believe it brings them a competitive advantage. (I'm not making judgements on whether they're right or wrong; vendors disagree on this, which is why I'm couching my response in these terms.) Thus the current unfortunate situation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: On Tue, Jul 30, 2013 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. That's type=datetime (the time zone is always UTC). Hmm.. .what does a JS dev use, then, when they want to require a user to have to pick a timezone other than UTC? There's no control in HTML today that exposes a time zone interface, whether it's UTC or anything else. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Parser-related philosophy
(I think these e-mails have largely been overtaken by events, but I promised to reply to all substantive feedback, so here we go.) On Sat, 12 Jan 2013, Vipul S. Chawathe wrote: It's okay for authors who leave deploying content to publisher to stop with looking at html appearance from browser to users. Xhtml's fewer publishers maybe bonded abit over-tightly with it if their quantity is lesser considering how helpful transforms are. Repetitive content over-counted is more likelier for html than transformable xml serializations. The publisher may favour plug-ins for flash, jvm, Silverlight and whichever else. However, small publishers who are impacted by semantic significance of content grasped by search engine, oft deliver same data using link tag with rel=alternate attribute than difficult to index proprietary plug-in based formats. The alternate representation might be atom, rdf, ... using grddl xslt or some such html sibling spec, so xhtml may not be well-supported but vanilla support is another matter. For my personal interest, I'm looking forward to seamless iframes, though styled iframe does hide the frame appearance for javascript that breaks on main xhtml page, and place it in another page that's plain html. My point is, if the spec can be precise w. r. t. DOM to avoid usability breakage in xhtml, then the spec hopefully will be precise, leaving aside when xhtml should be considered dead to user-supporters at present. I agree that the spec should be precise. If there's concrete examples where it's not, please do bring them up so we can fix them. On Mon, 14 Jan 2013, Henri Sivonen wrote: On Fri, Jan 11, 2013 at 10:00 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 Jan 2013, Henri Sivonen wrote: I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. Not just browser vendors. Authors rarely if ever use XML for HTML either. When you say use XML, do you mean serving content using an XML content type? I mean using XML that is processed as XML by one or more parts of the toolchain, as opposed to being treated as HTML (parsed by an HTML parser) or text (parsed by custom parsers or hand-edited in a way that doesn't check at any point for XML well-formedness), and contains nodes in the HTML namespace during this processing. Anyway, I'm not suggesting that they diverge beyond the syntax (which is already a lost cause). All I've concretely proposed is syntax for binding Web components in text/html; I haven't described how this should be represented in the DOM, for instance. If we define foo/bar as being a text/html syntactic shorthand for foo xml:component=bar, or foo xmlcomponent=bar, in much the same way as we say that svg is a shorthand for svg xmlns=http://www.w3.org/2000/svg;, then the DOM remains the same for both syntaxes, and (as far as I can tell) we're fine. I didn't realize you were suggesting that HTML parsers in browsers turned bar/foo into bar xml:component=foo in the DOM. How is xml:component=foo better than is=foo? It's exactly the same, as far as I can tell. It's the syntax that'd be better, IMHO. Why not bar foo=, which is what bar/foo parses into now? (I can think of some reasons against, but I'd like to hear your reasons.) Namespace collision. That space is taken up by defined attributes. Some of the constraints are: - The binding has to be done at element creation time - The binding has to be immutable during element lifetime - The syntax must not make authors think the binding is mutable (hence why the select is=map proposal was abandoned) How does xml:component=map suggest mutability less than is=map? It doesn't, but you wouldn't see that in the markup. - It must be possible to generate the syntax using a serializer that exposes (only) the SAX2 ContentHandler interface to an XML system and generates text/html in response to calls to the methods of the ContentHandler interface and the XML system may enforce the calls to ContentHandler representing a well-formed XML document (i.e. would produce a well-formed XML doc if fed into an XML serializer). The syntax must round-trip if the piece of software feeding the serializer is an HTML parser that produces SAX2 output in a way that's consistent with the way the parsing spec produces DOM output. (This is a concrete way to express “must be producable with Infoset-oriented systems without having a different Infoset mapping than the one implied by the DOM mapping in browsers”. As noted, dealing with template already bends this requirement but in a reasonably straightforward way.) Personally I don't think this is a requirement we should worry about. - It must be possible to generate the syntax with XSLT. (Remember, we already have !DOCTYPE html SYSTEM about:legacy-compat, because
Re: [whatwg] Stack trace in window.onerror
On Fri, 26 Jul 2013, James Greene wrote:
My last name ends with an 'e' ('Greene' vs. 'Green'). Please correct
that when you get a chance. Thanks!
Oops, my apologies. Fixed.
You had mentioned earlier that there is already a window 'error' event
that can be listened to via `window.addEventListener('error', fn,
false);` if you don't use `window.onerror = fn;`:
Or indeed if you do. They both fire.
Is that clarified in the spec somewhere already?
Yeah, this was a recent change.
Although that makes perfect sense to me, I have never noticed it before
nor heard of any browser vendors implementing such. Have there been any
such implementations yet? If so, that's *wonderful* news. :)
Some quick testing shows this working in at least Firefox and Chrome. That
is, the 'error' event fires. In Chrome it has attributes message,
lineno, and filename, but it doesn't seem to in Firefox.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modifying iframe sandbox attributes
On Mon, 22 Apr 2013, Tim Streater wrote: I need to add/remove the allow-scripts attribute to/from an iframe sandbox, since I use one frame for two purposes (sometimes with untrusted content, other times with my own content that uses JavaScript). I've tried the following: iframePtr.sandbox = allow-popups allow-same-origin allow-scripts; and: iframePtr.sandbox = allow-popups allow-same-origin; This doesn't appear to work in Safari 6.0.4. Is this the right syntax? Is such a possibility even implemented yet. It should work. Make sure you set them before you navigate the iframe, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script-related feedback
On Wed, 9 Jan 2013, Anne van Kesteren wrote: On Wed, Jan 9, 2013 at 9:32 PM, Ian Hickson i...@hixie.ch wrote: Advantages of putting this in JS over multipart: - it's backwards-compatible - it's easier to parse a static barrier than a multipart/*'s wacky syntax. - it doesn't impact any of the current fetching logic, since it's still just one resource instead of introducing a layer in between script's logic and the JS logic. - it automatically works anywhere you can use JS, not just where HTTP is involved. - it can be shimmed more easily (if you trust the JS not to have arbitrary injection and be written with the shim in mind, especially). - it doesn't run into weird problems like what if a part has the wrong MIME type. - it's way easier to deploy (authors hate having to set MIME types). - it doesn't run into the problem that all UAs have historically ignored the MIME type of script. Adding magic meaning to certain JavaScript comments seems like a pretty big downside though. Furthermore, multipart logic, however weird, is a sunk cost both on consumer and producer side, whereas introducing /*@BREAK*/ seems like a very steep uphill battle. And actually img is a precedent for checking a MIME type before sniffing/executing and it hasn't been much of a problem. (The problems there were mostly figuring out how SVG should work.) Yeah, but the multipart logic has pretty big disadvantages -- mainly the opposite of the advantages for a built-in feature: - not backwards compatible - not as simple to understand, use, implement, or spec - doesn't really work outside HTTP - harder to shim - more edge cases to define (e.g. what if the MIME types of the parts change unexpectedly) - requires setting MIME types, which authors hate I think JavaScript would be the logical place to support this. We don't use multipart/* logic to do incremental rendering of HTML, we don't use it for incremental rendering of images (only for animating them), why would we use it for incremental execution of script? I think scripts, just like image formats, HTML, XML, etc, should have built-in support for incremental processing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stack trace in window.onerror
On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! I've added a fifth argument to onerror, which has the exception object. On Fri, 12 Jul 2013, James Greene wrote: I'd rather get an Error-like duck-typed object with this shell info for cross-domain requests than to not get a real Error object when the unhandled error *is* from the same origin. For the cross-origin case, I've set error to null. Adding the trace as another new argument to `window.onerror` is certainly an option but the parameter list is getting long and I suspect that Error prototypes may still gain additional properties in the future. Yeah, exposing the error itself seemed better. On Fri, 12 Jul 2013, Elliott Sprehn wrote: Can we just add a new event that takes an event object instead of a huge list of arguments? :) There's already an event. You can get it if you use addEventListener() for 'error' rather than using onerror. (It's also exposed on the event object, for those of you using addEventListener() for error events rather than onerror.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on a variety of elements
On Mon, 31 Dec 2012, Pierre Dubois wrote: On Fri Dec 14 2012, Ian Hickson wrote: I don't think this works for all tables. For example, the first example in the spec in the th element's section does not get handled correctly by your algorithm -- it treats the ID column as important, instead of the second column. [Maybe I] did not [use] the correct word to identify that kind of cell that I named Key cell. The objective of the Key cell is to identify a td cell that have [...] relationships to a th cell at his right side in the same row. The td rowspan attribute would need to match or be lower than the corresponding th. The inverse would show a data cell td used as an heading cell th. If I understand correctly, you mean that you want to be able to automatically determine that the th here is a heading for the td: table tr td th /table The current relationships algorithm create a relationship for the preceding th cell not following th cell. Assuming you mean the one in the spec today: correct. That's partly because you never want to do this vertically, and the algorithm is direction agnostic (it uses the same steps for going left as going up), and partly because it's not clear how often you want to do this going left either. In particular, sometimes tables are of the form: +-+-+-+-+ | Header | Data| Header | Data| +-+-+-+-+ ...where the header cells are headers for the data to the right. Or, in a more difficult case to handle: +-+-+--+-+ | Header v| Header v| Metaheader v | | +-+-+--+-+ | Data| Data| Header | Data| +-+-+--+-+ | Data| Data| Header | Data| +-+-+--+-+ Without the scope= attributes, I don't think that table would make much sense. You have right that the proposed algorithm, for the first example in the spec in the th element's section does not get handled correctly. The question is: Why from a visual point of view, by excluding any styling, can you feel that Cats cell and the English speakers cell is know as a row group as highlighted in the source code with the scope attribute set to rowgroup? My answer is: Because the header cell is surounded by empty data cell in his row. For me that represent a mix of a layout table combined with a data table. A quick fix to the proposed algorithm would be at the end of the data row processing, do a test to know if the header cell is surrounded by empty data cell, that until the first real data row is found in the rowgroup (tbody) section. If that is true, the header cell scope can be determined as a rowgroup header and the surrounded empty data cell can be know as layout cell. Is that make sense? Have you another visual logic regarding that case? I don't know that we really need, or want, to make the current algorithm more magic than it already is. There's a point of diminishing returns where the complexity makes it too hard to debug. The algorithm is already pretty complex, maybe too much so; making it even more complex seems like a bad idea. Proposal: Table Usability API This is a very elaborate and large API. What are the use cases against which to evaluate it? i.e. what problem does it solve? The main use case is to parse a complex table and extract the data in the objectif to create an accessible (WCAG 2.0 Level AA compliant) chart by using the progressive enhancement strategy. The use of the table to create the chart remove the need for an web author to discus and sometime debate with the content provider in the objectif to build a descriptive text alternative version of the chart. Why can't this be done in script already? I don't understand why we need an API for this. Also the proposed Table Usability API is not just to handle complex table. The proposed API provide support access the tabular data either by his row or by his columns. Sometime, for presentational purpose, the axes are reversed. As an example took the following two row table. Do you think, for presentational purpose, it will be better have a two column table instead? I think both table, with equivalent structure, should be supported and have an equivalent accessible API. [long table] It's not clear to me that you need an API at all. The DOM API seems sufficient for this example. I mean, people hardly use the API we have already, why add another one, especially a big one? It just doesn't seem like a compelling enough problem for us to try to solve it. On Fri, 19 Oct 2012, Pierre Dubois wrote: Sometime the subsequent
Re: [whatwg] `window.location.origin` in sandboxed IFrames.
On Thu, 10 Jan 2013, Mike West wrote: In WebKit, loading 'iframe sandbox=allow-scripts src=frame.html/iframe' with a framed document containing 'scriptalert(window.location.origin);/script' alerts the actual origin of the document, which wasn't what I expected. I'm not sure what's intended, but I expected that treating the framed document as existing in a unique origin would have some effect on the string output as it's location's origin. Adam explained that WebKit currently treats the 'origin' attribute as the origin of the document's location, not the origin of the document[1]. This is generally benign, but surprised me in the sandboxed case. What should the expected behavior in this case be? Given the way that MessageEvent sets the origin of a message from a sandboxed frame to the string null, that seems like a reasonable option here as well. I guess we have to decide whether location.origin is exposing information about the location, or information about the page. Since it's on Location, I think it'd make sense to be information about the location; document.origin would be where I'd expect information about the page itself. When the page's origin doesn't match the URL's origin, the page's origin will always just serialise as null, so it's not clear that it's actually useful to expose that really anyway. What would the use cases be? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch: Origin header
On Wed, 6 Mar 2013, Anne van Kesteren wrote: It seems we have a bunch of different policies for setting the Origin header :-( XMLHttpRequest always sets it to the given value. HTML's fetch only sets it to a non-null value if a from parameter is passed. I originally wanted it to always be passed, but there are cases where that's not done for various reasons (mainly privacy or compatibility). The Origin spec handles this via privacy-sensitive contexts; if you look at the HTML spec source and search for privacy-sensitive you'll find relevant notes. HTML's potentially CORS-enabled fetch seems to never invoke fetch with a from parameter except indirectly via CORS' cross-origin request. Right, the idea there is to basically defer to CORS. On Thu, 7 Mar 2013, Anne van Kesteren wrote: So I also tested the fetch from an origin in the specification http://dump.testsuite.org/fetch/form.html and it turns out that only WebKit exhibits this behavior. Other browsers do not include Origin in a navigation that uses the POST method. This is unsurprising, it's new requirements in old parts of the spec and it's unlikely browsers will be updated until it's something we test in the test suite. On Fri, 8 Mar 2013, Anne van Kesteren wrote: Okay. So currently the mix of the Origin specification and the HTML specification suggests you either do Origin: /origin/ or Origin: null. However WebKit seems to do Origin: /origin/ or no header at all (for the privacy-sensitive cases). Ian also mentioned that we can not just put the Origin header into every outgoing request as that breaks the interwebs (per research you did for Chrome I believe?). Origin: null is what the Origin spec requires, I think, so we should update that spec if we don't do that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox and allow-scripts
On Fri, 12 Apr 2013, Ian Melven wrote:
Freddy Braun recently noticed that he could do the following in Firefox
:
iframe id='foo' sandbox='allow-same-origin' src='inner.html'
(note no allow-scripts)
and then in the document containing the iframe:
var iframe = document.getElementById('foo');
iframe.contentWindow.eval(alert(document.location));
and the alert will fire, which he found surprising.
I tested this in Chrome and IE 10 and found the behavior consistent
across all three browsers.
The relevant portion of the spec seems to be (from
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#enabling-and-disabling-scripting)
:
* Scripting is enabled in a browsing context if ... The browsing
context's active document's active sandboxing flag set does not have its
sandboxed scripts browsing context flag set.
is the intent in Freddy's case to apply this rule using the browsing
context of the script entry point ? that fits the implemented behavior,
but maybe should be mentioned in the iframe sandbox/allow-scripts
section of the spec ?
On Sat, 22 Jun 2013, Adam Barth wrote:
That's the behavior I would expect. You can also do the following:
var iframe = document.getElementById('foo');
iframe.contentWindow.alert(hello);
The allow-scripts sandbox flag doesn't block the script interfaces
inside the iframe. It just prevents content inside the iframe from
triggering script execution. In this case, the content outside the
iframe is the one triggering the script execution.
I agree with Adam that executing the eval() is consistent with the HTML
spec. The reasoning is that the eval is done by JavaScript itself, which
doesn't check if scripting is enabled when it runs the script. The
scripting-is-enabled stuff is only checked when HTML itself tries to
compile or run a script, e.g. in a script block or event handler.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Page reflow when entering/exiting fullscreen
On Mon, 22 Jul 2013, Matt Falkenhagen wrote: When an element goes fullscreen, should the browser try to retain the layout of the underlying document, e.g., by creating a placeholder for the element? With the top layer, it's possible to style the fullscreened element and ::backdrop such that the underlying document is visible. In such a case, it may be surprising for the user to see the layout change. The scroll position may also change. As far as I can tell, the Fullscreen spec doesn't say anything normative about retaining the layout. I'm wondering whether it was a deliberate decision to leave it up to the author to create a placeholder if desired. (As an implementer, this would be easier for me.) WebKit and Blink actually already use a placeholder to prevent the page from reflowing when entering/exiting fullscreen, but there are some limitations. For example, inline elements don't get placeholders. How would you know how to style the placeholder? e.g. if you change the body font-size while full-screen, and the element that is now full-screen was, previously, styled using 'em' units or some such, but is now styled using pixels or %s? Or if there was something based on :hover, or dynamic class changes, e.g. every element on the page is styled using explicit pixel dimensions, with one dimension when the elements have class A, and another when they have class B, and the page changes all the elements to class B -- how do you know that in this case, you should update the placeholder? This seems hard to define. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, 22 Jul 2013, Dirk Schulze wrote: scale(0) is invalid, and should throw an exception. I don't think that we want to throw an exception on scale(0). No browser does that today. WebKit did it in some places in the past but removed the exceptions. WebIDL says it should throw a TypeError, because it's missing an argument. (Step 4 of the overload resolution algorithm). Firefox, Chrome, and Safari all seem to do this. The second does setTransform(0,0,0,0,0,0), which should reset the CTM to a zero matrix (again, not invertible). IE, Opera and FF draw a line to 0,0 and close the path afterwards (which kind of makes sense, since the universe is convoluted to one point). WebKit refuses the lineTo command and closes the path as expected. WebKit seems to just be wrong here, and the others right. Since this is not written in the spec As far as I can tell, it _is_ written in the spec. scale(0,0) would reduce all coordinates and lines and so forth to 0,0. That's what the spec requires. I don't see the problem here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Background of body covering the whole page – is this described somewhere?
On Tue, 23 Jul 2013, Jukka K. Korpela wrote: 2013-07-23 20:44, Anne van Kesteren wrote: On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Is this described somewhere in HTML or CSS specifications or drafts? I think it should be, since it is what browsers do (tested on Firefox, Chrome, IE), and even though it sounds absurd, I’m afraid pages may rely on it. A natural place to look at is http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-page but I can’t find any statement about the body element extending to cover the viewport as far as backgrounds are considered. http://www.w3.org/TR/CSS2/colors.html#background Thanks for the prompt reply. Makes things clear. On the practical side, however, I wonder whether this part of CSS specifications should be referred to in the Rendering section, as it is logically rather unexpected. There's a lot of these kinds of things (e.g. lots of things are dependent on quirks mode, there's a bunch more like the background that are dependent on the MIME type, etc). Short of duplicating the entire CSS spec in the HTML spec (which would be my preference, modulo logistics around editing -- I think we should just have one Web spec), it seems impractical to actually mention all of them in the HTML spec. This is why we don't list them currently. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menu and friends
On Mon, 31 Dec 2012, Jonas Sicking wrote: On Fri, Dec 28, 2012 at 11:07 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Dec 2012, Jonas Sicking wrote: I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I'm happy to give guidance that happens to match what the browser vendors want to do anyway, but I don't think it makes sense to make a page- undetectable UI detail like this a conformance requirement. I agree that defining exact UI is a bad idea. However I think we should define the semantic meaning of the context menu. If the semantics are that the context menu provided by the page is intended to be additional context actions, or alternative context actions. I've tried to add more text to the spec to encourage UAs to not show the UA menu items as prominently. Is that sufficient? We're constrained in what we can do, given that this is UI stuff. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? As a user, I would hate that. But if you as a browser vendor are telling me as a spec writer that this is what would be needed to convince authors to not use divs for context menus, then yes. What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. Sure. Honestly, though, I think the bigger blocker right now is that there's only one implementation (and it doesn't match the spec). You are the one that is requesting that we only have a single mode. Well, I think in general it's pretty uncontroversial that, all other things being equal, APIs are better if they have less surface area. So sure, I'd rather we not have multiple modes if we don't need them. If we are to fulfill both these requirements then yes, we end up with something that both you and I would hate in many cases. The alternative that I have proposed, but that you so far have rejected, is the ability for the author to select mode, i.e. select if he/she wants to replace or add to the existing menu. If the options are: - authors never use the feature - users lose their control over their browser - the feature has a complicated API ...then we're stuck in a bad place, certainly. But I don't think those are the only options; what about these, for instance: - authors use the feature anyway, and like that it gives users power - browsers default to showing mainly the author's menuitems, but offer a discoverable way for users to find more options if they need them Ok, the first of these two might be too optimistic, but the second should be workable, no? That's what the spec now suggests. I've added an example that shows how this could work: Before (only the author's commands): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-collapsed.png After (the user having clicked a disclosure widget): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-expanded.png As a user, what I would like to be the behaviour, without the ability for the author to override it, is for the context menu to have the author's context menu items plus the context-sensitive items that cannot be accessed via the regular menus (e.g. Inspect Element, View Image, Copy Link Location, that kind of thing). The ability to override the authors request of replacing the context menu seems like a quality of implementation issue. For example I would imagine that Firefox would hook up the already existing allow authors to replace context menu UI option to control whether the nodefault attribute was honored. Likewise chrome could supply an extension to do the same thing. Personally, I don't want to prevent authors from providing me with features. I just want to prevent them from removing features. What I want is the union of the site's features and the browser's features. Firefox's allow authors to replace context menu UI option is IMHO insufficient. I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. I'm very skeptical about adding any kind of control here before we have broader implementation experience. Once we do, then it will be revisited anyway, since we have this bug on file: I doubt that I can change your mind on this. But I'll note that that means that that likely means that we'll have to make the default behavior the behavior that you like less. I think it's possible to have a default behaviour
Re: [whatwg] Canvas-related feedback
On Thu, 20 Dec 2012, Rik Cabanier wrote: On Thu, 20 Sep 2012, Dirk Schulze wrote: On Sep 21, 2012, at 3:12 AM, Ian Hickson i...@hixie.ch wrote: The only situation that might be reasonable would be a transform on the Canvas that an author want to cover in the Path. But for the rare case where this matters, you can create a new Path object, add your path with the transform and call isPointInPath. Yeah, you could do that too. Furthermore, a transform() function that applies to a Path object seems to be useable as well. You can create a new Path, then add another Path to it while applying a transform, using the addPath() method. Yes, it is possible. But there are two reasons why I think that it still makes sense to use a transform function. First it seems natural to have a transform on Path object, like the CanvasRenderingContext2D already has. Both share a lot of functions, why disallow it for transforms? The main reason I didn't add it to Path is because it led to a bit of confusion in terms of what the transform applied to. Does it apply when you add points _to_ the path? Does it apply when you draw the path on another path or the canvas? Also, one of the more confusing aspects of the canvas API is that you can change the coordinate space while adding lines to the path, and we had a whole era wherein implemenations and the spec were confused as to what exactly happened when (did the points get transformed? Did the transform apply only when you stroke? etc). So in the new API I side-stepped the whole problem. I don't understand. How did you sidestep the problem? By not having a transform on Path. It is still confusing. for instance, reading the current spec, transforms happen before stroking in addPathByStrokingPath, but after stroking in addPathByStrokingText. Why is that? That was just an oversight. Fixed. Thanks. Wouldn't it be easier to have API's that - create a path with svg path data - create a path with text (and a style) - stroke a path with a style - add a path with a optional transform How does this differ from what we have? Do you just mean move the Text-based methods from being add*() methods to being Path constructors? I guess we could do that, I don't really see a compelling argument one way or the other. The current model is to use add*() for as much as possible; the only non-trivial constructors we have are a copy constructor, for convenience, and the SVG-based constructor, which is not an add*() method because I didn't want to try to explain how SVG path processing interacted with existing subpaths. We also should discuss what 'adding' a path means. Currently, the shapes are simply aggregated which will only work for simple cases. Proposals welcome. :-) On Fri, 21 Sep 2012, Rik Cabanier wrote: On Fri, Sep 21, 2012 at 2:12 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 20 Sep 2012, Dirk Schulze wrote: The interface of CanvasRenderingContext2D currently has a function called isPointInPath() with a Path object as input [1]. I wonder why this needs to be on the context interface. Wouldn't it make more sense on the interface of Path object itself? If an implementation really needs a context to get a point on a path it, it can create it on it's own. I don't think it would make _more_ sense, but I agree that it would make equal amounts of sense. In practice you're pretty much always going to have a context around when you want to check this, because the reason you'd use it is to see where I mouse click landed on a canvas. And you're going to want the Path object transformed as per the transform on the canvas, generally speaking. Not necessarily. The path object makes sense outside of canvas as well. You don't need a context to create it so we are thinking of integrating it with SVG. It would increase interop and simplfy the API's if you could ask SVG elements for their path, or create them with one. Sure, but with SVG you don't need to know if a point is in a path, because the events get dispatched to the right path by the UA. That assumes that you always have an event handler attached to the path. No, not at all. Even if the event handler is a global listener, it still gets the target information in the event object. This might not always be the case. For instance in a game, you might want to know what region of the character you hit. I don't see how having a isPointInPath method on a Path object would help with that. You'd still need to have the path transformed; if this was canvas, you'd want to check each of the actual paths against the actual canvas (or more likely, use a hit region), if it was SVG, you'd check what the target of the event was. Maybe if there was a 'currentpath' property on the 2d context, you
Re: [whatwg] Undefined action parsing HTML fragment with select context
On Sun, 21 Jul 2013, Nolan Waite wrote: Hello! I am confused about parsing an HTML fragment when the context is a select element. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#parsing-html-fragments step 4.6 instructs me to reset the parser's insertion mode appropriately. I head over to http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#parsing-html-fragments but I see a problem in step 4. In step 4.1 I let ancestor = node. At this point, I have: - stack of open elements = - html - last = true - node = the context element, a select element - ancestor = the context element, a select element In step 4.2 ancestor is not the first node in the stack of open elements (the context select element is not and has never been on the stack), so I continue to step 4.3. Now I am to let ancestor be the node before ancestor in the stack of open elements. There is no such node! At this point, ancestor is not on the stack of open elements, so there is no node before it. I assume the intention is to effectively jump to the step labeled *done* if ancestor is the context element? That makes sense to me. Oops. Fixed. Your other bug (about whether math and svg are supposed to get foster parented) is also valid, but harder to fix, so I added it to the queue but haven't fixed it yet. (The short answer is yes, they're supposed to be foster parented.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support
On Wed, 17 Jul 2013, Edward O'Connor wrote: On Wed, 30 Jan 2013, Peter Carlson (carlsop) wrote: Problem: The problem is that the supported playback speeds of a media element may vary per media item (e.g., an on-demand movie) and as […] Recommendation: We suggest that the application should be able to discover the available speeds at which it can play the media element. […] This seems less good than just having the browsers support all playback speeds, e.g. by decoding into a local buffer. Why would we prefer to expose the media's limitations rather than removing them? Live streams. Do you really think browsers should have to pause and buffer a live stream to make it possible to play it in FFWD? Sure. Just like a DVR. On Wed, 17 Jul 2013, Peter Carlson (carlsop) wrote: For on-demand movies or VOD, the available playback speeds may be determined by the server of the content. This cannot be overcome by client-side buffering. Um... no? The user should be in control. Always. On Thu, 18 Jul 2013, John Mellor wrote: If the user is speeding up playback to improve their productivity (spend less time watching e.g. a lecture), then they may well be willing to wait until enough of the video is buffered, since they can do something else in the meantime. For example by spending 30m buffering the first half of a 1 hour live stream, the user could then watch the whole hour at double speed. Obviously the UI should make it clear what's going on (rather than lengthily buffering without explanation). Right. Just like a DVR. On Thu, 18 Jul 2013, Brendan Long wrote: This is how DVR's work with live TV and people seem to like it (well, they like it more than not being able to fast-forward at all..). Indeed. On Thu, 18 Jul 2013, Eric Carlson wrote: And it works because a DVR has lots of disk space. This is not the case with all devices that support the media element. Obviously device limitations are difficult, but realistically, HTML-capable devices now regularly have gigabytes of storage available. The spec doesn't require that the entire infinite stream be buffered, only as much as is possible; there's a whole bunch of prose about how to handle discarding content once the buffer is full (earliest possible position and so on). Even a DVR, however, won't always let you change the playback speed. For example it isn't possible to play at greater than 1x past the current time when watching a live stream. Well obviously you can't fast-forward into the future, but you can pause and buffer some, or rewind if you've been watching for a while, and fast-forward through the buffer. If I am watching a live stream and I try to play past the end of the buffered video, my DVR drops back to 1x and won't let me change the speed. It doesn't automatically pause and buffer for a while so it can play at a faster rate. Sure. That's fine. The spec has lots of prose that describes the requirements around how to handle playing content back when there's not yet content available to play back. It isn't always possible to play a media stream at an arbitrary speed. It is foolish to pretend otherwise as the current spec does. If you can play it at 1x speed, then you can rewind and play it at 2x speed, or 0.5x speed. That's all the spec says. On Thu, 18 Jul 2013, Brendan Long wrote: That makes sense, but we also don't want to limit ourselves to playback speeds that a server supports when the client /does/ have data buffered. Right. What if we added a supportedPlaybackRates attribute, which holds an array of playback rates supported by the server, plus (optionally) any rates the user agent can support due to the currently buffered data (possibly requiring that the user agent have enough data buffered to play at that speed for some amount of time). Wouldn't that be 0.0 .. Infinity, basically? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alignment of empty buttons
On Thu, 25 Apr 2013, Christian Biesinger wrote: I had to recently investigate issues with the alignment of empty buttons, i.e. button/button, and I noticed some browser differences. Specifically, take this testcase: http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hz1PdQFcAYMbARIYUVkcAYYOfp8Zo6WFn6KkXphDVlVVUE+bnZ8aEawBsk8dEJaYmB11HwEdtLa4H8PNt08fA14A Where should the button be positioned relative to the input field (or if you prefer, the baseline of the block)? Chrome dev, IE and Opera put the bottom of the button a bit higher than the bottom of the input, whereas Firefox seems to approximately center the button on the line (though without using vertical-align:middle). Chrome stable puts the top of the button slightly below the top of the input. Any suggestions for what the right behavior here is...? Note that this isn't an entirely academic question, because websites do use empty buttons (styling them with a width, height and background image). On Thu, 25 Apr 2013, Boris Zbarsky wrote: The question you are really asking is where is the baseline of the button?, right? Gecko puts the baseline of the button at the baseline of the button's text, and if the button is not auto-height the extra height is added (or removed) equally from above and below the text. It looks like Chrome dev does the same unless there's no text in the button, in which case they put the baseline at the bottom margin edge (more inline-block-like behavior?). On Thu, 25 Apr 2013, Christian Biesinger wrote: Hm, but I don't think that's completely correct, because then the positioning should stay the same when I start entering text in the button, right? Or does adding text make the text run have height, affecting where the extra height gets added? I think what you are saying is: in Gecko, baseline of a button is (content_box_height - text_height) / 2 + text_ascent On Thu, 25 Apr 2013, Boris Zbarsky wrote: If I recall exactly how this code works, if there is no text then the baseline goes at the bottom of the (empty) content box and then the extra height is added on both sides. Once you have text the baseline goes on the baseline of the text, which is slightly above the bottom of the content box to allow for descenders. The spec claims that: # When the button binding applies to a button element, the element is # expected to render as an 'inline-block' box rendered as a button whose # contents are the contents of the element. What this means exactly... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2413 I think the buttons and the divs in this example should basically have the same dimensions and positions (colours might differ). Nobody seems to quite agree, but I can't work out what they're doing exactly (or why). The spec seems like a pretty sane middle ground, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Rendering] zero width attributes on table, th, td should be ignored
On Wed, 2 Jan 2013, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#tables says: # The table element's width attribute maps to the dimension # property 'width' on the table element. ... # The td and th elements' width attributes map to the dimension # property 'width' on the element. These rules should have an extra condition to say that any zero value (be it a zero integer or a zero percentage) is ignored rather than mapping to the 'width' property. They already do: maps to the dimension property is defined in terms of rules for parsing dimension values, which never returns a value less than 1; the value 0 is treated like an error. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas 2D memory management
On Wed, 9 Jan 2013, Ashley Gullen wrote: Some developers are starting to design large scale games using our HTML5 game engine, and we're finding we're running in to memory management issues. Consider a device with 50mb of texture memory available. A game might contain 100mb of texture assets, but only use a maximum of 30mb of them at a time (e.g. if there are three levels each using 30mb of different assets, and a menu that uses 10mb of assets). This game ought to fit in memory at all times, but if a user agent is not smart about how image loading is handled, it could run out of memory. [...] Some ideas: 1) add new functions to the canvas 2D context, such as: ctx.load(image): cache an image in memory so it can be immediately drawn when drawImage() is first used ctx.unload(image): release the image from memory The Web API tries to use garbage collection for this; the idea being that you load the images you need when you need them, then discard then when you're done, and the memory gets reclaimed when possible. We could introduce a mechanism to flush ImageBitmap objects more forcibly, e.g. imageBitmap.discard(). This would be a pretty new thing, though. Are there any browser vendors who have opinions about this? We should probably wait to see if people are able to use ImageBitmap with garbage collection first. Note, though, that ImageBitmap doesn't really add anything you couldn't do with img before, in the non-Worker case. That is, you could just create img elements then lose references to them when you wanted them GC'ed; if that isn't working today, I don't see why it would start working with ImageBitmap. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] coordinate space definition bogus?
On Tue, 29 Jan 2013, Dirk Schulze wrote: I think the definition of coordinate space is misleading in the specification. # The canvas element has two attributes to control the size of the # coordinate space: width and height. This implies that the coordinate space is limited by this size. This is not the case. The coordinate space can be transformed and scaled all the time. In theory the size of the coordinate space is infinite. But the size of the surface could be defined by 'width' and 'height'. Yeah, that's bogus. I've tried to fix the text. The same problem occurs with the definition of clipping regions, that by default, depend on the size of the coordinate space. A simple scale and drawing over the size of the 'width' and 'height' values demonstrate that the clipping region can not be measured by the size of the coordinate space (or it could, if it is assumed to be infinite). For clip, why isn't it possible to just say that clip() does not clip if there is no currentPath? This would at least avoid this trap. Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] remove resetClip from the Canvas 2D spec
On Tue, 29 Jan 2013, Rik Cabanier wrote: we were looking at how resetClip could be implemented in WebKit. Looking over the Core Graphics implementation, this feature can't be implemented without significant overhead. I also found an email from 2007 where Maciej states the same concern: http://permalink.gmane.org/gmane.org.w3c.whatwg.discuss/10582 The solution on Mac is probably for Apple to update CoreGraphics to support this feature. This is a quite widely requested feature. Since no browser has implemented it, can it be removed from the spec? It's new, so no browser having implemented it is expected. If browsers don't implement it, it'll get removed in due course. But it would be sad for authors, who are the main concern here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Tue, 29 Jan 2013, Dirk Schulze wrote: The spec doesn't have any wording about the behavior on non-invertible CTMs on Canvas contexts. Is it still possible to add segments to the current path once a CTM is not invertible anymore? Does the path get rejected completely then? Implementations are fairly different. Here are two examples (code attached at the end of the mail as well): http://jsfiddle.net/Dghuh/1/ http://jsfiddle.net/Dghuh/2/ Note that the path is stroked after restoring the initial CTM in both examples. The first one does scale(0), which should make the CTM non-invertibe, WebKit still applies lineTo and closePath for some reason. IE and FF refuse to draw anything. scale(0) is invalid, and should throw an exception. If you do scale(0,0), the browsers act the same as with your second test that uses setTransform() with 6 zeros. The second does setTransform(0,0,0,0,0,0), which should reset the CTM to a zero matrix (again, not invertible). IE, Opera and FF draw a line to 0,0 and close the path afterwards (which kind of makes sense, since the universe is convoluted to one point). WebKit refuses the lineTo command and closes the path as expected. WebKit seems to just be wrong here, and the others right. This is an edge case, but should still be clarified in the spec. I don't understand what there is to clarify. In both cases, the behaviour seems well-defined: if you're transforming everything to zero, that's what the result will be. Zero. Firefox's behaviour is the right one. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sortable Tables
to provide external links or buttons that can:
- Sort by a column as described in 1.
- Sort by a column, force ascending
- Sort by a column, force descending
You can do that, just change the sorted= attribute values accordingly.
I believe that this could be achieved with the following additions:
- a th.sortedstate attribute to question if the table is currently sorted by
this column, and if yes in which direction
You can already do that. If the th has a sorted attribute, it's sorted
by that column; if it's value contains the keyword reversed, it's
reversed. (If it contains a number greater than 1, it's not the primary
sort column, so you might want to look for another column too.)
- th.sort() method would take an optional argument to indicate the desired
sort direction
You can do that as follows:
th.sort();
th.sorted = 'reversed';
This will always make that th be the primary column, sorted in reverse.
The algorithm for th.sort([String direction]) could then be extended somehow
like the following (to be simple I just write th for the column header
element that the method is applied to):
- Temporarily set the column key ordinality of th to 0
- If the direction argument is provided (and valid), temporarily set the
column sort direction to direction
- Else if the sortedstate attribute of th is not null
- if it is asc, temporarily set the column sort direction to desc
- else temporarily set the column sort direction to asc
- Perform the table sorting steps
- Set the sortedstate attributes of all column headers to null
- Set the sortetstate attribute of th to the column sort direction
- Reset the column sort direction and the column key ordinality of th to their
initial values
Wouldn't that break the way that previous sort columns become secondary
sort columns?
Furthermore, a table.sort() method would be handy. It could take a comma
separated string as an argument, with each token being the ID of a th, and
optional the direction, such as:
button
onclick=document.getElementById('pirates').sort('sex asc, age')
Order pirates by age, women first. Click again for descending age.
/button
You can do that today without much script already:
script
var headers = document.getElementById('pirates').tHead.rows[0].cells;
var ascending = false;
function sort() {
headers.sex.sort();
headers.age.sort();
if (ascending)
headers.age.sorted = 'reversed';
ascending = !ascending;
}
/script
button onclick=sort()
Order pirates by age, women first. Click again for descending age.
/button
I don't think a utility method to do this is much of a win. Maybe once
this sorting algorithm is widely implemented and we see what people do a
lot, we can consider adding things like this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
forward events and styles, I don't think there's any problem with the rest of this relying on message passing. At that point it's only sizing, after all.) On Mon, 14 Jan 2013, Nasko Oskov wrote: The input events was just one example. There are other cases where having an asynchronous boundary can lead to unexpected behavior for developers. * The current spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless) calls for merging the collection of links between seamlessly nested documents: For example if the user agent supports listing all the links in a document, links in seamlessly nested documents would be included in that list without being significantly distinguished from links in the document itself. If the parent document is trying to access the set of links, while the link has been removed from the nested document, there will be a race condition. I think you're misreading this. It's only referring to user interface, not to DOM APIs. On Tue, 15 Jan 2013, Markus Ernst wrote: The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. Both sites would be made vulnerable to each other, but if we make it so both sites have to explicitly opt-in to accepting the other site before the embedding could be seamless, this seems somewhat safe to me. It's unlikely that one site is going to want to be embedded in a hostile site, or vice versa, and explicitly allow it. Unless we allow wildcard embeddings, in which case the embedded resource is at the mercy of hostile sites. On Fri, 18 Jan 2013, Markus Ernst wrote: I did not mean to merge origins, but to completely detach the included resource from its origin, and allocate it to the origin of the including document: - Document from A domain-A.com includes resource B from domain-B.com - Resource B has set AllowSameOrigin=domain-A.com - Document A and resource B can access each other as same-origin - Now Resource B tries to access resource C from domain-B.com - Resource C does not have AllowSameOrigin specified for domain-A.com - Resource B cannot access resource C, as it would violate the same-origin policy. Resource B is treated as of origin domain-A.com. I don't know whether this is possible, but I think if yes, it would be an elegant solution to this topic. This would violate all kinds of assumption in the platform. For example, what localStorage could they read? What XMLHttpRequests could they perform? What domain would a WebSocket have to accept connections from? Having the URL of the page not match its origin would lead to all kinds of issues, also. This sounds like a disaster waiting to happen. But anyway, none of this is necessary. Even if the embedded page is in the same process, it can still be cross-origin, even in a system that usually isolates origins. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: createImageBitmap should return a Promise instead of using a callback
On Wed, 19 Jun 2013, Justin Novosad wrote:
I was about to launch the implementation of window.createImageBitmap in
Blink, and I received feedback on the blink-dev mailing list that the
Promise API is the wave of the future for asynchronous JS, and that
the new createImageBitmap method should use Promises.
Current spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#images
The proposal is to change the ImageBitmapFactories IDL to something like
this:
[NoInterfaceObject]
interface ImageBitmapFactories {
Promise createImageBitmap(ImageBitmapSource image, optional long sx, long
sy, long sw, long sh);
};
The value of the promise would resolve to an ImageBitmap object.
Done.
On Thu, 20 Jun 2013, Anne van Kesteren wrote:
I think something like
interface ImageBitmap {
static Promise create(ImageBitmapSource image, optional long sx,
long sy, long sw, long sh);
};
would be much nicer.
Why?
On Thu, 20 Jun 2013, Justin Novosad wrote:
I agree it would be nicer, but it seems less consistent with other
existing APIs.
Indeed.
On Thu, 20 Jun 2013, Tab Atkins Jr. wrote:
There's really no consistency here anyway, and the Interface.create()
idiom is pretty easy and nice.
There are basically two styles:
- constructors (new Date(), new Function(), etc)
- factory methods on the parent object (document.createElement(),
implementation.createDocument(), context.createLinearGradient(), etc)
I don't think we have anything that uses the interface.create() pattern.
URL.createObjectURL() is the closest, and it's not a factory.
The constructor pattern is obviously better where possible, but in this
case it's not, since it has to be async (hence Promises).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: createImageBitmap should return a Promise instead of using a callback
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote: There are basically two styles: - constructors (new Date(), new Function(), etc) - factory methods on the parent object (document.createElement(), implementation.createDocument(), context.createLinearGradient(), etc) Do we have a strategy for moving to Promises for all sync factory methods across the API? Using Promises vs the issue of the factory method names are two orthogonal issues. We can't change old APIs to use Promises (and indeed in most cases they're not needed, e.g. all those I cite above). If you don't need a promise, you should really just use a constructor. I'm asking because it seems like a big change of programming pattern and not everyone may be ready to move on from the old one yet (read: this is next generation technology), so would it be better to keep both interfaces around for a while? We can never remove functionality. I don't think it's ever good to have duplicate functionality. But in this case I think this is a non-issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: createImageBitmap should return a Promise instead of using a callback
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
In this case you did remove the non-promise based approach - presumably
because it has not been implemented in browsers yet, which is fair
enough for browsers.
Right.
However, for JS developers it means that if they want to use this
function, they now have to move to introduce a Promise model in their
libraries.
Not really. You don't have to use the promise API for anything other than
a callback if you don't want to.
As in, if your code uses the style that the HTML spec used to have for the
createImageBitmap() example:
var sprites = {};
function loadMySprites(loadedCallback) {
var image = new Image();
image.src = 'mysprites.png';
image.onload = function () {
// ... do something to fill in sprites, and then call loadedCallback
};
}
function runDemo() {
var canvas = document.querySelector('canvas#demo');
var context = canvas.getContext('2d');
context.drawImage(sprites.tree, 30, 10);
context.drawImage(sprites.snake, 70, 10);
}
loadMySprites(runDemo);
...then you can still do this with promises:
var sprites = {};
function loadMySprites(loadedCallback) {
var image = new Image();
image.src = 'mysprites.png';
image.onload = function () {
// only the comment from the snippet above is different here:
Promise.every(
createImageBitmap(image, 0, 0, 40, 40).then(function (image) {
sprites.woman = image }),
createImageBitmap(image, 40, 0, 40, 40).then(function (image) {
sprites.man = image }),
createImageBitmap(image, 80, 0, 40, 40).then(function (image) {
sprites.tree = image }),
createImageBitmap(image, 0, 40, 40, 40).then(function (image) {
sprites.hut = image }),
createImageBitmap(image, 40, 40, 40, 40).then(function (image) {
sprites.apple = image }),
createImageBitmap(image, 80, 40, 40, 40).then(function (image) {
sprites.snake = image }),
).then(loadedCallback);
};
}
function runDemo() {
var canvas = document.querySelector('canvas#demo');
var context = canvas.getContext('2d');
context.drawImage(sprites.tree, 30, 10);
context.drawImage(sprites.snake, 70, 10);
}
loadMySprites(runDemo);
The promises are very localised, just to the code that uses them. But
then when you want to use them everywhere, you can do so easily too,
just slowly extending them out as you want to. And when two parts of
the codebase that use promises touch, suddenly the code that glues
them together gets simpler, since you can use promise utility methods
instead of rolling your own synchronisation.
I'm just dubious whether they are ready for that yet (in fact, I have
heard that devs are not ready yet).
Ready for what?
At the same time, I think we should follow a clear pattern for
introducing a Promise based API, which the .create() approach would
provide.
I don't understand what that means.
I guess I'm asking for JS dev input here...
Promises are just regular callbacks, with the synchronisation done by the
browser (or shim library) rather than by author code. I don't really
understand the problem here.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: createImageBitmap should return a Promise instead of using a callback
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote: We have the same issues with WebRTC, which already has a callback based API, but there is a suggestion to replace/augment with a Promise based API, so I just wanted to understand the motivation, potential complications and implications. WebRTC's constructor is synchronous, no? There are callbacks, sure; there are callbacks all over the place in the Web platform. Promises themselves use callbacks. I don't understand the relevance to createImageBitmap(). One issue is the change in API paradigm that we use. People have got used to wrapping the callback API with a Promise style API when they need it. Now they have to do both: wrap the browser API for a Promise style API and wrap it for a callback style API. You don't have to wrap it for a callback style API. It _is_ a callback- style API. The only difference is the order of arguments. Instead of: foo(success, failure); ...you write: foo().then(success, failure); It's hardly cumbersome. It may well be that Promises are the right way to go for createImageBitmap(), but we are blazing a new trail here and need to be careful about the implications. As far as I can tell, the only implications are that you can later use the Promise utility methods to combine things together, so you don't have to manage the callbacks yourself. This seems like a win. For example, here is an interesting discussion thread with a statement that node.js originally used Promises, but moved away from them for several reasons, not least because they created a 20% performance degradation with v8: https://github.com/gladiusjs/gladius-core/issues/127#issuecomment-5212272 I think you're massively misreading that parenthetical. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on Web Worker specification
On Thu, 22 Nov 2012, Fred Andrews wrote: Why would the user disable JavaScript if they wanted the page to act like JavaScript was enabled? To avoid scripts leaking private state accessible via the DOM and other APIs the user could disable or restrict JS in contexts that have access to the DOM or other APIs. The 'web worker' like context would not have access to the DOM or other APIs and thus not be a security risk and could be allowed access to the web to forward information into the UA secure context. It is also proposed that the 'web worker' like context receive defined intentional input from users. I don't understand the security model here, or the attack vector you are concerned about. Who are we trying to protect the DOM from? How would a script running in a worker be able to cause any effect that the user could see, if the script cannot communicate with a script that does have access to the DOM? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Tue, 16 Jul 2013, Takayoshi Kochi (河内 隆仁) wrote: IIUC WebKit uses internally node's language to determine which font to use to render text, e.g for Han unification (https://en.wikipedia.org/wiki/Han_unification) WebKit has to choose a proper glyph depending on its lang attribute for the same Unicode codepoint. Sure, but internal UA uses aren't use cases for the Web. The use cases Peter gave over the weekend are valid, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] proposal: Add support for masking to canvas
On Fri, 1 Feb 2013, Cameron McCormack wrote:
On 30/01/13 6:28 PM, Ian Hickson wrote:
That's weird. heycam, can you elaborate on this? The addHitRegion()
case in particular never makes sense to be called without a dictionary
containing at least one member. Do we have to allow it?
This is to encourage (require, really) API design that allows the
dictionary object to be not specified at all. Remember that all
dictionary members can be not specified anyway.
Do you want addHitRegion() to throw just like addHitRegion({}) would
throw? That will happen if you already have wording to say that
addHitRegion({}) will throw.
Ah, ok. Fixed. Thanks.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Feature requests that I've converted to bugs
Over the years I've collected a number of threads on this list that were requesting features (as opposed to reporting bugs), and which lacked immediate interest from more than one browser vendor. Unfortunately, while I've been tracking them, they don't have much visibility and so I don't always know if a particular topic has grown more interest from implementors, since vendors don't know to tell me. To address these problems, I've gone through the feature request threads, and extracted from them all the use cases and constraints I could find, and then using that filed bugs for each feature request. Here are the bugs I filed (and some earlier ones that covered the same topics, for completeness): canvas Aligning strokes inside or outside a path https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 Features to control the Referer header https://www.w3.org/Bugs/Public/show_bug.cgi?id=22675 APIs for page prerendering https://www.w3.org/Bugs/Public/show_bug.cgi?id=22676 video expose the frame rate and specific frames of media resources https://www.w3.org/Bugs/Public/show_bug.cgi?id=22678 Localisation https://www.w3.org/Bugs/Public/show_bug.cgi?id=21289 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679 Make FormData expose its contents https://www.w3.org/Bugs/Public/show_bug.cgi?id=22680 Make input type=file.files writable https://www.w3.org/Bugs/Public/show_bug.cgi?id=22682 Web Intents https://www.w3.org/Bugs/Public/show_bug.cgi?id=22683 Inline script async https://www.w3.org/Bugs/Public/show_bug.cgi?id=22696 An API to detect palpable content, so you can tell in an editor if a paragraph is empty https://www.w3.org/Bugs/Public/show_bug.cgi?id=22697 API to make canvas prettier when printing https://www.w3.org/Bugs/Public/show_bug.cgi?id=22698 Expose the origins of ancestor frames https://www.w3.org/Bugs/Public/show_bug.cgi?id=22699 Inline Web worker scripts https://www.w3.org/Bugs/Public/show_bug.cgi?id=22700 Full form autofill triggered by page request https://www.w3.org/Bugs/Public/show_bug.cgi?id=22701 appcache: More detailed error information https://www.w3.org/Bugs/Public/show_bug.cgi?id=22702 canvas Masks https://www.w3.org/Bugs/Public/show_bug.cgi?id=22703 canvas Layers https://www.w3.org/Bugs/Public/show_bug.cgi?id=22704 I have also been keeping track of feature requests and which browser vendors are interested in implementing which features on the wiki: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest I urge implementors who are interested in implementing any of these features to say so in the bugs or on the wiki page, so that I know which features are ripe for speccing, and which would just get ignored. (If you are bcc'ed to this e-mail, you probably contributed to a thread that resulted in one of the bugs above being filed. A few people may have been bcc'ed who did not contribute to these threads. Please accept my apologies for any inconvenience caused.) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Wed, 17 Jul 2013, Tobie Langel wrote: On Tuesday, July 16, 2013 at 7:53 PM, Ian Hickson wrote: Can't you do window.isSameOrigin by just trying to access window.location.href and seeing if you get an exception? Unfortunately not, because of the previously mentioned WebKit bug which logs an error message but doesn't throw (so there's no way of knowing whether an exception was thrown or not). We can trivially change that, if that's the only problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
users.
I think a fully automatic solution that tries to use subpixel AA but is
always able to render grayscale AA if needed is the way to go. Possibly
with an author hint to suggest opting into a more expensive rendering
path.
[...]
On Wed, 13 Mar 2013, Gregg Tavares wrote:
Sorry for only mentioning this so late but is there any chance to steer
this to be more inline with WebGL?
WebGL already has the option to have an opaque canvas using context
creation parameters. In WebGL it's
gl = canvas.getContext(webgl, {alpha: false});
[...]
On Fri, 19 Apr 2013, Stephen White wrote:
Here's a short proposal I've written up for the getContext('2d', {
alpha: false } ) version of this idea (much of it culled from the
mega-thread above).
http://wiki.whatwg.org/wiki/CanvasOpaque
Seems reasonable; who is implementing this?
On Wed, 13 Mar 2013, Gregg Tavares wrote:
But, there are other context creation attributes we'd like to see on a
2d canvas. One that comes to mind is 'preserveDrawingBuffer'.
preserveDrawingBuffer: false in WebGL means that the canvas is double
buffered. This is a performance win since most browsers using GPU
compositing need to copy the contents of the canvas when compositing.
Setting preseverDrawingBuffer: false (which is the default in WebGL)
means the browser can double buffer and avoid the copy. We'd like to see
that same attribute for 2D canvas/contexts to get the same perf benefit
for canvas games, etc.
So, given we want more creation attributes and given WebGL already has a
way to declare opaqueness why not follow the existing method and add
context creation parameters to 2d canvas to solve this issue rather than
make a new and conflicting 'opaque' attribute?
On Fri, 15 Mar 2013, Gregg Tavares wrote:
What about a context attribute antialiasRenderingQualityHint for now
with 2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
[...]
How about these, is anyone interested in implementing these?
On Tue, 12 Mar 2013, Stephen White wrote:
As an example, the darker compositing mode was removed from the spec
due to hardware-accelerated performance concerns, IIRC.
No, it was removed because it had no spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding blending to the canvas API
On Tue, 16 Jul 2013, Rik Cabanier wrote: This feature has landed in both Blink and Firefox. Firefox shipped it somewhere around February while Blink will have it in the next major release of Chrome. Can this be added to the WhatWG canvas spec? Yeah. Integrating with the Compositing and Blending spec is on my TODO list. I currently owe you a response to: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0229.html ...which involves doing that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AudioTrack enabling - missing behaviour in the specification
On Tue, 18 Dec 2012, Aleksander Wabik wrote: Current AudioTrack spec says: The AudioTrack.enabled attribute, on getting, must return true if the track is currently enabled, and false otherwise. On setting, it must enable the track if the new value is true, and disable it otherwise. (If the track is no longer in an AudioTrackList object, then the track being enabled or disabled has no effect beyond changing the value of the attribute on the AudioTrack object.) This leaves us no place for disabling tracks by the player. It would be fine for the player's user interface to offer a way to enable or disable specific audio tracks. Tracks can only be enabled by the web application, and when enabling multiple audio tracks at once, they all have to be played. The specification does not define in any way what should happen when there are not sufficient resources to enable all requested tracks, and it's especially important on embedded systems ([smart]phones, TVs, etc). The spec says only: User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. This is unfortunately not enough. The spec should require a certain behavior when running out of audio tracks, so that we don't end up with one browser enabling the newest track while another browser rejects the newest track, for instance. Regardless of what we do, unless we require a specific limit that all browsers can and do implement, we'll end up with some browsers playing all the tracks, and some not. Regardless of which tracks are not playing, that seems like it's a pretty bad interoperability problem. I don't see how specifying which tracks are to be disabled would help. In particular, what if some tracks are more expensive to play than others on some hardware? The requirement is that you play all the enabled tracks. If you fail to do that, you're not going to have a good time. To me the most natural behaviour would be to always enable the track which was requested to enable and, if needed, disable the least recently enabled track. What if you can't play the most recently requested track, e.g. because it is in a format that your hardware can't handle? (e.g. too great a bitrate or something) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feature Request for the-video-element to support audiochannel descriptions
On Wed, 23 Jan 2013, Christian Horn wrote: Hello to everybody, unknowingly, It would be nice to see audioTrack.channels added to the-video-element for media resources with multiple media tracks. It should return the number of channels in the audio track (1 = mono, 2 = stereo, 6 = surround, etc). A use case can be: A user has an encoded video with multiple audio tracks. Track 1 and 2 are both English, but one is stereo, one is surround. Can you elaborate on the use case? Wouldn't the browser be the one in the best position to know which to pick, in that case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support
On Wed, 30 Jan 2013, Peter Carlson (carlsop) wrote: Problem: The problem is that the supported playback speeds of a media element may vary per media item (e.g., an on-demand movie) and as supported by the underlying platform. Currently the application has to discover the supported speeds by trial and error or by an alternative non-HTML5 method that links to the media element. Recommendation: We suggest that the application should be able to discover the available speeds at which it can play the media element. These speeds provide the allowed playbackRate values. These speeds are provided as attributes of the media element. This seems less good than just having the browsers support all playback speeds, e.g. by decoding into a local buffer. Why would we prefer to expose the media's limitations rather than removing them? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Details on window.open
On Tue, 18 Dec 2012, Boris Zbarsky wrote: On 12/18/12 3:53 PM, Ian Hickson wrote: Per the spec, calls that would create a new browsing context are blocked unless called from the handler of a trusted 'click' event. That's not web-compatible... I don't know if the spec is overly strict here; maybe it should also be possible on other trusted events e.g. mousedown or keydown? Gecko's current behavior is as follows: [...] I strongly suggest talking to all UA vendors about how their popup blockers actually worked. The Gecko setup used to be simpler, but we've had to add complications to it as we came across site compat issues... I've tried to spec something that's close to what you describe and what other vendors have described to me. It's better, but it's still not perfect; if there's some way in which it is inadequate, please don't hesitate to report it. I haven't tried to spec it, because as far as I can tell, UAs could completely ignore it with no ill effects. If I'm wrong about this, then we should spec something. I think on desktop you're somewhat wrong (e.g. it's possible to get site compat bugs where you open a window at the wrong size and users can't get to content)... Can't they just resize the window or scroll it? What happens on UAs that don't have sized windows, like most implementations of browsers on phones? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Details on window.open
On Mon, 15 Jul 2013, Boris Zbarsky wrote: On 7/15/13 4:44 PM, Ian Hickson wrote: Can't they just resize the window or scroll it? It depends. It's common to open these windows non-scrollable (which UAs usually obey) and unresizable (which they don't necessarily obey) Fair enough. What happens on UAs that don't have sized windows, like most implementations of browsers on phones? The pages are completely unusable. That describes a whole lot of pages... Seems like we should stop obeying making pages unscrollable. I haven't adjusted the spec to honour the details on window.open(), given the above. In particular, since some UAs can't honour them anyway, it seems wise for more UAs to just ignore them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Fri, 12 Jul 2013, Peter Occil wrote: Well, my true hope is that such a DOM attribute like language will be specified in the HTML or DOM spec. Especially since it's not currently possible to get the language of a node through JavaScript methods alone. What's the use case for having this in HTML? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Baseline of objects
bz wrote: On 12/28/12 1:42 PM, Jonas Grus Dinesen wrote: I am looking for a feature to set the baseline of an object, fx an svg figure (rectangle, triangle etc) which makes it possible to let fx height and width of an object grow upwards and not downwards. Maybe by setting horisontal and vertical baselines. For vertical, see http://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align (specifically the percentage and length values). On Mon, 31 Dec 2012, Jonas Grus Dinesen wrote: I can see that the explanation was not really good. It's not the content of the element but the element it self I am referring to. What I have in mind is maybe an x- and y axis that could be replaced in the bottom or top(x axis), to the left or right(y axis). Actually this axis could be placed anywhere inside the element and make it possible for the element to increase or decrease its width and height in both directions, exactly like Flash can do it. This seems like a presentational/styling request. I recommend approaching the CSS working group. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reporting errors during Web Worker startup
On Wed, 9 Jan 2013, Kenneth Russell wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#creating-workers doesn't seem to define what happens if there aren't enough resources to create a separate parallel execution environment. User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. -- http://whatwg.org/html/#hardwareLimitations Would it be legal for a UA to consider this as violating a policy decision and throw SecurityError? Or is that step intended to reflect a static decision, such as whether the UA allows workers to run at all? If this behavior isn't specified, could some graceful failure mode be specified? Currently some UAs terminate the execution of the page attempting to start the worker, which is obviously undesirable. We can't really define behaviour in hardware-constrained situations, because you might not have the resources to do what the spec requires. (In the most trivial case: the spec right now technically requires that when you don't have enough resources to start a new worker, that you start a new worker anyway. Obviously you can't do that.) Implementors are encouraged to not have limits, but when you hit the limits, you just need to do what seems best. My recommendation here would be to just queue the worker up and wait for there to be available resources. Or, even better, to run workers in a thread pool, and when you have more workers than threads, time share the threads between the workers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] supporting HTMLElement.dataset on SVG elements
On Wed, 6 Feb 2013, Cameron McCormack wrote: As part of aligning SVG with some not-so-HTML-specific features of HTML, the SVG WG would like to support data-* attributes on SVG elements. In mixed HTML/SVG documents, it seems like you would want to be able to use these attributes regardless of whether the elements are HTML or SVG, or indeed MathML. Does it make sense to move HTMLElement.dataset up to Element, so that all elements can benefit from it? If not, could this attribute be split out on to a separate interface that we could have SVGElement implement? (I'm also going to be looking at the other global attributes that HTML elements have to see if any make sense in SVG too.) Fine by me. Anne on IRC suggests that maybe we should wait to see evidence that browsers are adopting the changes we've made so far (e.g. moving 'id' to Element, getting rid of the animated class stuff from SVG), before we start making even more changes on this front. That seems reasonable. Anyway, whenever this gets added to Element, I'll remove it from HTMLElement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A question about portrait-secondary of screen orientation
On Fri, 8 Feb 2013, Chundong Wang wrote: Hello - Got a question of screen orientation on portrait/landscape. Let's say we have a device doesn't support portrait-secondary, by spechttp://www.w3.org/TR/screen-orientation/ we should remove it from allow list which is fine. However if web developer specified portrait instead of portrait-primary for lockOrientation(), which I suppose is a common case, we'll have to expand it to portrait-primary, portrait-secondary according spec. In this case the lockOrientation() would fail because orientations isn't a supported orientation set. I don't think it'll satisfy the original purpose of portrait. IMHO, we should explain this more detailed. We could either, 1. Only expand portrait(or landscape) into allowed orientations, or; 2. Filter out disallowed orientations from orientation sequence and lock the screen with that list. I believe feedback on this specification is intended to be sent to public-weba...@w3.org. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML Specification update request: bug 20939
On Sat, 9 Feb 2013, Bob Owen wrote: While discussing with Boris Zbarsky, some work I am doing on sandboxing for Mozilla, we realised that the sections in the HTML specification on browsing context security and browsing context names, could do with some clarification with regard to the effects of sandboxing. http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-nav http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-names The non-normative table, in the browsing context names section, does cover many of the effects. However, if the normative text in these two sections is read on its own, without knowledge of the sandboxing sections, then the reader could easily come away with an incorrect understanding. I have raised the following bug detailing all of this. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20939 The bug also contains some suggestions for new rows that could be added to the non-normative table. I resolved that bug. As a general rule, I encourage people to either file bugs or send e-mail feedback; sending both just ends up making one of them get a response like this one. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canonical Image and Color
On Mon, 11 Feb 2013, Brian Blakely wrote: Meta elements for defining a canonical image and color to be associated with the page(s) in which they are included. This is intended for use by user agents and third-party applications (such as social networks), referred to collectively as parsers in this document. It is inspired by Microsoft's recent work in site pinning and Apple's standalone webapp implementation in iOS Safari. meta name=image content=path/to/image.png / meta name=color content=#123456 / * Image Value may be a relative or absolute path to file. No restrictions on filetype or resolution. May also be an animated image or video format. Filetypes supported and handling therein is relegated to the parser. * Color Value may be any of the CSS named colors, hex codes, RGB, HSL and their alpha-channel variants. Once attained by the parser, use is at that parser's discretion. You are welcome to register these on the wiki and convince people to use them, sure. Seems like they already have solutions, though, as you show: On Mon, 11 Feb 2013, Brian Blakely wrote: * Social network sharing Facebook currently scrapes OpenGraph tags from shared pages to create a content snippet. One such tag is og:image, which specifies the image to display in that snippet. Twitter and Google+ use these same tags in addition to their own implementations for developers. For the title and description of the snippet, scrapers will fall back to title and the meta description. A canonical image would serve the same purpose, but for visual content. Sounds like this is already solved, then. * News aggregation Flipboard, a highly visual, magazine-style news and article reader, displays a hero image from the target page. It does this by parsing and analyzing the img elements in a page, sometimes displaying a non-optimal or even vacant result. A canonical image would allow developers to control this kind of representation with more specificity, and provide the 3rd party app with another presentation option. Why don't they use the data that Facebook, Twitter, and Google+ use? * OS Integration Apple currently parses their own apple-touch-icon element that specifies which image will serve as a web application's icon after the user has added to the homescreen. Android's browser uses this same element, while Microsoft uses a similar msapplication-TileImage. When these element is not specified, a screenshot of the website is used instead or, in Microsoft's case, the favicon. Firefox OS has still another means of implementation for this. A canonical image could either replace or provide an additional fallback for this functionality. Why isn't link rel=icon sizes= sufficient? * Color In all these cases, a canonical color allows external parsers to provide further branding or additional flourish in their representation of apps and pages. Microsoft's msapplication-TileColor and msapplication-navbutton-color elements aim to fulfill this purpose in IE by coloring the app's tile on the Windows 8 homescreen and IE's own navigation UI, respectively. Seems like there's already a solution, then. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why are we merging Document and HTMLDocument again?
On Thu, 14 Mar 2013, Anne van Kesteren wrote: On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/5/13 3:30 PM, Ian Hickson wrote: I'd be fine with having a Document descendant that is used for Documents that have global scopes / browsing contexts / the works, and one that is used for Documents that don't (e.g. createDocument(), XHR); would that address this issue? It's one way to address it, yes... Just to be clear, this works for Mozilla, as long as it's clearly defined and other vendors are on board. Arv? Having not heard any interest from anyone else, I haven't done anything. If there's movement here, let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Schemes for registerProtocolHandler
On Mon, 11 Mar 2013, Simon Pieters wrote: While looking at our testsuite for register*Handler I noticed that we seem to support some schemes that are not in the spec: im (works like xmpp says wikipedia) ircs (secure equivalent of irc) wtai (apparently prompts the user what to do with the phone number provided) They seem to be in line with those currently in the list. Should they be added to the spec? Added. BTW, the spec's list is not in alphabetical order. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Wed, 20 Mar 2013, Boris Zbarsky wrote: The spec for document.referrer says: The referrer attribute must return the document's referrer. The document's referrer is not really defined anywhere in a useful way that I can find. What's not useful about the way it's defined? It's set to a specific string. This then follows with a non-normative note: Note: In the case of HTTP, the referrer IDL attribute will match the Referer (sic) header that was sent when fetching the current page. In cases when the hostname is non-ASCII, the Referer header will have it encoded in punycode. Is that defined anywhere? The question is what should happen for document.referrer. The spec says (normatively, not just in the note) that it's the exact string that the HTTP spec says must be generated for the Referer: header. See the Creating a new Document object algorithm: http://whatwg.org/html/#create-a-document-object ...which refers to the fetch algorithm, which refers to HTTP. Right now, I see the following behavior: 1) Gecko shows exactly the string we put on the wire in document.referrer (punycode and all). document.URL and document.location.href show the non-ASCII chars in some cases. That's correct per spec (assuming the punycoding is required anywhere). The latter two are set separately than document.referrer: http://whatwg.org/html/#set-the-document's-address If other browsers don't match this, file bugs on them. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img loading events - can load error fire for the same image?
On Fri, 5 Apr 2013, Jake Archibald wrote: Been reading the steps for image downloading - http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data As far as I can tell: Step 12 If selected source is null is the only step where an error event can be fired and abort before step 14. Step 14 always results in firing a load event, either because the image download was successful and the user agent was able to determine the image's width and height, or Otherwise. Then if either the image data is corrupted in some fatal way such that the image dimensions cannot be obtained, or the image data is not in a supported file format an error event is fired. Unless I'm reading it wrong, that suggests http://jsbin.com/ifihex/1/editshould fire a load then an error, which doesn't feel right. I don't think the Otherwise step should fire load, just loadend. This has either been fixed already, or I don't understand the problem. Can you look at the spec again and see if it's ok now? Related: load is fired once the width height can be determined, which suggests that an un-decodable image, but with intact headers (which give the width height) will fire load but not error. Right. I agree with this, as it means the browser can defer decoding to render time, but do we need a way in JS to confirm an image is decodable? What's the use case? (Surely the server should check this on the server.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scrdoc and session history don't play along in the spec
On Fri, 5 Apr 2013, Boris Zbarsky wrote: The session history algorithm in the spec navigates to urls. That wasn't the intent. I've tried to clarify it. As far as I can tell, on the face of it, this means that this testcase: iframe name=x srcdoc=aaa/iframe a target=x href=http://web.mit.edu; Click me, then later hit back /a should fail to go back. It should load the original resource. Again, as far as I can tell; actually telling anything for sure about the navigation/shistory part of the spec is impossible. :( You know, it's disheartening to work on something and have you continually insult it like this. Please stick to positive feedback, which you are quite good at providing, and avoid the non-constructive negative commentary. Thanks. On Sat, 22 Jun 2013, Adam Barth wrote: One tricky case here is what happens if you modify the srcdoc attribute: iframe id=foo srcdoc=aaa/iframe script [...] // Wait for the iframe to finish loading. document.getElementById(foo).srcdoc = bbb; [...] // Wait for the iframe to finish loading. document.getElementById(foo).contentWindow.document.body.innerHTML = ccc; /script What happens if you click the back button now? I believe that in WebKit and Blink, you'll get bbb. That's because we navigated back in the history to about:srcdoc, which then looked at the srcdoc property and saw bbb even though the srcdoc property had aaa when that history entry was created. If I'm not mistaken, the spec requires it to be aaa, since that's what resource was loaded for the first session history item. I don't see anything in the spec that allows bbb to be shown. On Sun, 23 Jun 2013, Adam Barth wrote: I guess it depends on what you mean by rely. We just treat the about:srcdoc URL as something that, when fetched, retrieves the value currently stored in the srcdoc attribute. That doesn't seem defensible per the spec. In fact, the spec explicitly says that about:srcdoc is unresolvable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forcing orientation in content
On Thu, 18 Apr 2013, David Bruant wrote: Currently working on a web project where tablet support (iPad especially) is important, I'm facing a need which apparently the platform doesn't support. I would need to lock the screen in landscape mode. Why? As a user on desktop, I can resize my window however I want, to be landscape or portrait. Why wouldn't I be allowed to do the same on any other device? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Wed, 24 Apr 2013, Peter Occil wrote: Well in my case, I have written an HTML parser in Java and C# [1][2], which parses HTML documents and returns an object that implements a subset of the DOM, so far. As far as possible, I included only methods and attributes that were specified in the DOM or HTML specification, such as the characterSet attribute (which is called getCharacterSet on my DOM's IDocument interface), and more recently the innerHTML attribute (which is called getInnerHTML on my DOM's IElement interface) However, when I decided to implement an RDFa processor based on my HTML parser, I had need to include a method that returns the language of a node (see, for example, section 3.3 of reference [3]). As a result, I included a method called getLanguage on my DOM's INode interface (which may correspond to a possible--future--DOM attribute called language on the Node interface). I feel uneasy having to include this extension to what ought to be a subset of the HTML DOM. Implementations of HTML and the DOM are allowed to have internal methods to do things like this. There's no reason to limit yourself to the API visible to JavaScript. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alignment of empty buttons
On Fri, 3 May 2013, Boris Zbarsky wrote: On 5/3/13 7:07 PM, Christian Biesinger wrote: fantasai pointed out that CSS does specify this: If the box does not have a baseline, align the bottom margin edge with the parent's baseline. (http://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align) Yes, but that _if_ the box does not have a baseline. CSS does not specify what replaced elements do or do not have baselines (and it's not completely clear even whether button is a replaced elements)... The HTML spec is pretty explicit about it not being: # When the button binding applies to a button element, the element is # expected to render as an 'inline-block' box rendered as a button whose # contents are the contents of the element. -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reorganizing and fixing origin
On Wed, 22 May 2013, Anne van Kesteren wrote: As Bj?rn points out in http://www.ietf.org/mail-archive/web/websec/current/msg01512.html defining origin of a URL in terms of STD66 is broken. So we should define it in terms of the URL Standard. The Origin header also has problems, as it suggests you can have a space-separated list, which we disallowed almost immediately after the Origin RFC was published and the IETF group did not accept errata for. Now Origin of a URL can be defined in the URL Standard (not done yet). I put an updated definition of the header here: http://fetch.spec.whatwg.org/#http-origin-header Where should we put the definition of origin itself? Back in HTML? I guess it still is mostly. What exactly is it you want moved, from where to where? Just the origin of a URL? I'm guessing Adam would be interested in revving the Origin spec to be more accurate if there's a problem with it; that would be my preference if at all possible. See also Adam's response to the message you cite above: http://www.ietf.org/mail-archive/web/websec/current/msg01520.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inert nodes and element.click()
On Thu, 23 May 2013, Matt Falkenhagen wrote:
I have some questions about these concepts.
1. For an inert element, what happens on element.click() or
element.dispatchEvent(new Event('click'))? The spec says an inert node
is treated as absent for the purposes of targeting user interaction
events [1]. My interpretation is that the element receives the 'click'
event as usual; the intent is to block actual user interaction, e.g., if
user the physically clicks on the element.
Right, inert= has no effect on .click() (and certainly has no effect on
manual dispatch; that works on anything, it just doesn't usually do
anything surprising -- for example, it doesn't click a button or link the
way that .click() does.) The inert= attribute basically just makes
clicks not work and prevents focusing (so you can't activate things by
keyboard either).
2. The definition of element.click() seems ambiguous. The spec says:
The click() method must run synthetic click activation steps on the element.
[2] There is a 6 step algorithm for synthetic click activation steps
followed
by a separate 6 step algorithm for when a pointing device is clicked. Below
that is a note which seems to say the above happens when the click() method
is called [3]. It's ambiguous what the above refers to and if it's the
second
algorithm, that seems to contradict the click() definition text.
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#inert-subtrees
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#activation
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#run-synthetic-click-activation-steps
The notes are non-normative, but I've tried to clarify what it means. Let
me know if it's still confusing.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Wed, 9 Jan 2013, TAMURA, Kent wrote: On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Sep 2012, TAMURA, Kent wrote: * For date, datetime, datetime-local, month, time, week, the attribute returns a string in a field. If a field is text-editable, it should return user-editing string like email and number. If a field has a fixed localized date/time string chosen by a date/time picker, the attribute should return the localized string. [...] - We can enable text field selection APIs for email, number, and other types How would this work when the control isn't a text control? I don't understand. For example, consider a date control that is actually three separate text fields (year month day); how do you envisage the selection API working and how would rawValue help with this? I think it's ok that rawValue doesn't work with form controls without any text. One of use cases of rawValue would be to handle user input errors. I think non-text form controls should be clever enough to avoid bad user input. For example, users can't set bad values to input[type=range]. I still don't understand how this would work. You suggest that it should work for type=date, but how? What happens when it's mutated by script, for instance? I really don't understand the purpose here or how it would work to achieve that purpose. - JavaScript-based screen readers can read user-visible content of input fields. Screen readers don't have to be limited to the HTML APIs. I'd expect a screen reader to have a much more intimate API to talk to the UA. There are some platforms of which native API is HTML. e.g. Chrome OS, Firefox OS, etc. Though Chrome OS can provide such API as chrome extension API, we had better have a standard API. I disagree. HTML is built on top of native APIs, even in Firefox OS and Chrome OS. It doesn't make sense to make HTML have all the APIs needed to talk to the OS. On Tue, 11 Sep 2012, TAMURA, Kent wrote: Yes, I'd like to enable selection API for at least type=email and type=number. All of their existing implementations are text fields. I haven't seen a request to suport selection API for type=email, etc.. However lack of selection API looks a defect to me. Why does the page need to touch the selection? It must be same as input[type=text]. e.g. - A page author wants to select the whole value or nothing of an email form control when it gets focus. Why is that a valid thing for a page to be doing? The browser should take care of doing that, not the page. If the page does it, it'll be different on each page and the user will get confused. - A user entered an email address with unacceptable domain name. A page author wants to move the caret to the beginning of the domain name. How is that possible in the case of a custom e-mail widget where the e-mail address isn't shown, but a user picture and name is shown instead? I just don't see how this is workable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
