[whatwg] HTML Namespace Elements
Hello Everyone. In the tokenizer specifications of the HTML5 parser the following is written : Otherwise, if there is a current node and it is not an element in the HTML namespace What does it mean ? It is linked to this page http://www.w3.org/1999/xhtml which doesnt provide any information regarding the HTML namespace. Any help is much appreciated. Thanks :)
Re: [whatwg] HTML Namespace Elements
* Mohammad Al Houssami (Alumni) wrote: In the tokenizer specifications of the HTML5 parser the following is written : Otherwise, if there is a current node and it is not an element in the HTML namespace What does it mean ? http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-NodeNSname is the string 'http://www.w3.org/1999/xhtml'. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] iframe srcdoc definition not compatible with existing user-agent user interfaces
On 4/8/13 1:20 AM, Ian Hickson wrote: If a browser can cache the data for a frame based on which frame it is rather than just its URL In Gecko's case, say, it's cached based on URL and a sequence number (to handle POST). If it can be made to work for POST, I don't see why srcdoc= would be any harder. Just treat it the same way. As in store in the HTTP cache? I suppose that could be done, in theory, but it would require rewriting how the HTTP cache interacts with the world... And yet in practice they are (not quite, but in the end similar). So the question is whether we should make that work or whether we just break it and expect all existing UAs and UA extensions to update. I don't think those are the only options. Sure, but the spec currently picks the second one of those two options, fwiw. Well, as Rob said, arguably the mentioned UIs don't really apply here anyway, so maybe they should just not be shown. Indeed. My point was to raise a concern about this, in case it hadn't been considered, not to suggest a specific solution. I don't have a specific solution to suggest. Note that nothing in the spec mentions these UI features at all Sure. At the same time, the existing UI feature set of UAs, and how feasible it is to support those features with new technologies we add, is worth considering when we spec new technologies. Just as a thought. I don't know that I have much more to contribute to this thread, honestly... -Boris
Re: [whatwg] Notifications: reviving Notification objects
On Apr 4, 2013 12:53 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 31/03/13 15:33, Anne van Kesteren wrote: There are a couple of scenarios http://notifications.spec.whatwg.org/ does not address at the moment. A) User navigates to chat site. Chat site creates a notification from a chat with P while the user does something else. User closes chat site and then navigates to chat site at a later point. I guess a better example would be that the website is unloaded on memory pressure but the tab is kept. Otherwise, an explicit user action could be considered as enough to remove all currently opened notifications. I don't think that we want to impose the requirement that UAs have to close all notifications when the user closes the webpage that opened them. Or that UAs have to do that in order to not have dangling notifications. It seems like a reasonable UI to leave notifications opened once the user has granted explicit permission for a website to create notifications, as is the case any time they use the notifications API. / Jonas
Re: [whatwg] iframe srcdoc definition not compatible with existing user-agent user interfaces
On Mon, 8 Apr 2013, Boris Zbarsky wrote: On 4/8/13 1:20 AM, Ian Hickson wrote: If a browser can cache the data for a frame based on which frame it is rather than just its URL In Gecko's case, say, it's cached based on URL and a sequence number (to handle POST). Why does the test I posted fail, then? http://damowmow.com/playground/demos/ui/001.html Right-click either frame, and make it display the frame elsewhere (new tab, only-this-frame, even view-source is broken on this test in Gecko). The new page that's shown is different than the one the user interacted with. This isn't academic, it breaks any case where a frame's contents are dynamically generated. For example, an ad system that just uses an iframe and generates an appropriate ad each time would open a different ad if you were to right-click on it and open the iframe in a new tab. And yet in practice they are (not quite, but in the end similar). So the question is whether we should make that work or whether we just break it and expect all existing UAs and UA extensions to update. I don't think those are the only options. Sure, but the spec currently picks the second one of those two options, fwiw. No. The current spec doesn't even mention these features. It doesn't pick anything. Implementing them based on URLs doesn't work in all cases, even before srcdoc= was introduced. If you were to implement a multiply by two feature by simply shifting the input's first byte left by one bit, then it would work great for numbers up to 128. It would fail for numbers greater than that. The solution is not well, we should make sure all numbers are less than 128, or this solution works fine for most numbers that people actually come across. The solution is to use an algorithm that works all the time. This is a quality-of-implementation issue. There's nothing in the spec that means that these features have to use URLs; using URLs is ok for a first approximation but it doesn't handle all the cases (even ignoring srcdoc). The better implementations would work in all cases (including the example above and srcdoc). The less good implementations would not work in all cases, or maybe won't offer the feature at all (e.g. Chrome, as far as I can tell). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Add more types of DOM as part of Form
Recently I am working with some web frameworks with mongodb(non relational database). There is one type of field called dict, similar with BSON, or JSON. In general, when defining a table in db in modern frameworks, it also can be generated a form in html, which is intuitive and convenient. Well, but those types such as list, dict in db are not supported in the generation of a form in those frameworks. For example, if you have a field typed list, you need a html DOM something like a list of input type=text/, and the length can be changed dynamically. Of course, you can do define those things by hand. But since the non relational db will be used more, also in Semantic web. It will be much simple for web designer or programmer. The same for dictionary type.
Re: [whatwg] Add more types of DOM as part of Form
Hello jingwei lv, I am not sure, but, here is my try about your suggestion. As I understand, in your use-case, you may want to use the datalist / element: http://html5doctor.com/html5-forms-introduction-and-new-attributes/#list After that, I wonder what more you may want in the feature you are describing. Regards. Renoir Boulanger Frontend software developer. Montreal, Canada, QC. On 2013-04-08, at 8:44 PM, jingwei lv phoenixlv0...@gmail.com wrote: Recently I am working with some web frameworks with mongodb(non relational database). There is one type of field called dict, similar with BSON, or JSON. In general, when defining a table in db in modern frameworks, it also can be generated a form in html, which is intuitive and convenient. Well, but those types such as list, dict in db are not supported in the generation of a form in those frameworks. For example, if you have a field typed list, you need a html DOM something like a list of input type=text/, and the length can be changed dynamically. Of course, you can do define those things by hand. But since the non relational db will be used more, also in Semantic web. It will be much simple for web designer or programmer. The same for dictionary type.
Re: [whatwg] iframe srcdoc definition not compatible with existing user-agent user interfaces
On 4/8/13 6:57 PM, Ian Hickson wrote: Why does the test I posted fail, then? http://damowmow.com/playground/demos/ui/001.html Right-click either frame, and make it display the frame elsewhere (new tab, only-this-frame Those don't do the right thing; they just use the URI. even view-source is broken on this test in Gecko). It works for the later-loaded frame. Note that these are both GETs, not POSTs, so the sequence number thing is not used... The new page that's shown is different than the one the user interacted with. Yep. -Boris
