Re: [whatwg] Character-encoding-related threads
2012-06-29 23:42, Ian Hickson wrote: I consider all boilerplate to be a significant burden. I think there's a huge win to making it trivial to create a Web page. Anything we require makes it less trivial. It's a win, but I'm not sure of the huge. When learning HTML, it's an important aspect, and also when typing HTML by hand, but then it's mostly a convenience - and it helps to avoid annoying problems caused e.g. by making a single typo in a DOCTYPE declaration. So !DOCTYPE html is really an improvement Currently you need a DOCTYPE, a character encoding declaration, a title, and some content. I'd love to be in a position where the empty string would be a valid document, personally. Is content really necessary? The validator.nu service accepts the following: !DOCTYPE htmltitle/title I don't think we can get rid of DOCTYPE anytime soon, as browser vendors are stuck with DOCTYPE sniffing. But the title element isn't really needed, and unless I'm mistaken, the current rules allow its omission under some conditions - which cannot be tested algorithmically, so conformance checkers should issue a warning at most about missing title. It might be better to declare title optional but strongly recommend its use on web or intranet pages (it might be rather irrelevant in other uses of HTML). Yucca
[whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
According to http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection *HTMLCollection* returns the first element. *HTMLAllCollection* returns the first element or another HTMLAllCollection if there are multiple elements *HTMLFormControlsCollection* returns the first element or RadioNodeList if there are multiple elements *HTMLOptionsCollection* returns the first element or live NodeList if there are multiple elements *HTMLPropertiesCollection* returns PropertyNodeList In particular, I'm puzzled that HTMLAllCollection, HTMLFormControlsCollection, and HTMLOptionsCollection all return different objects. Why? Can those 3 classes somehow return the same object? FWIW, WebKit has always returned a static node list. Best, Ryosuke Niwa Software Engineer Google Inc.
Re: [whatwg] seamless iframes and event propagation
It's been pointed out to me that what I'm asking for is essentially the same retargeting as we do for shadow DOMs in web components, where the iframe is the shadow host and the document is the shadow root. This covers all the details of what properties need to be updated when crossing the document boundary. The only addition on top of that is that we need to convert the coordinate space of mouse events appropriately when we cross the boundary. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting Ojan On Mon, Jul 9, 2012 at 4:26 PM, Ojan Vafai o...@chromium.org wrote: I'd like to see us add event propagation into the parent document for seamless iframes, e.g. key and mouse events inside a seamless iframe should be refired on the iframe element. Use-case 1: A global key event handler for keyboard shortcuts. Without propagating the events, you need to add a key handler to each seamless iframe's root in order for these keyboard handlers to work when the iframe has focus. Use-case 2: A dragging UI. Without event propagation, if you don't add handlers to the iframe's root, you would just stop dragging when the mouse is over seamless iframes. In addition, the coordinates of the mouse event should be changed to the parent document's coordinate space when it is refired on the iframe, otherwise your code needs to know when it's over an iframe. We should fire two events. One inside the iframe and one on the iframe element itself (in the parent document). Any pointers to DOM nodes in the event would need to be nulled out in the event fired in the parent document if the seamless iframe is cross-domain and non-CORS accessible. This makes seamless iframes more seamless. Most existing keyboard shortcut and dragging JS code would magically keep working without needing to know anything about seamless. Use-case 3: Making an email client that wants the content of the email isolated from the client's UI, but doesn't want a nested scrollbar (i.e. the editable area sizes to the emails size). In this case, you don't want to inherit the CSS for the mail client into the email's content. Similarly, you may not want your global keyboard handlers to run when typing in the editable area. Similar to Adam's allow-seamless proposal, I'd like to see seamless have the ability to tweak which bits of the frame act seamlessly. Adam's proposal has inherit-styles. We could also add propagates-events to allow-seamless. Both of those would be off by default. For seamless, we could have no-inherit-styles and no-propagate-events in order to disable either behavior, also off by default. Ojan On Sat, May 26, 2012 at 5:16 PM, Adam Barth w...@adambarth.com wrote: Hi whatwg, I've added a proposal to the wiki http://wiki.whatwg.org/wiki/AllowSeamless about letting a document indicate that it is willing to be displayed seamlessly with a cross-origin parent. This proposal is a refinement of the approach previously discussed in this thread: http://old.nabble.com/crossorigin-property-on-iframe-td33677754.html. Let me know if you have any feedback. Thanks! Adam
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Fri, 13 Jul 2012, Ryosuke Niwa wrote: According to http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection *HTMLCollection* returns the first element. This is for compat in the default case, I believe. *HTMLAllCollection* returns the first element or another HTMLAllCollection if there are multiple elements This is needed for IE compat. *HTMLFormControlsCollection* returns the first element or RadioNodeList if there are multiple elements This is needed to support the radio button value feature. *HTMLOptionsCollection* returns the first element or live NodeList if there are multiple elements This is for compat, I believe. (We don't want to return just a node if there are many matching.) *HTMLPropertiesCollection* returns PropertyNodeList This is to support the value features for microdata. Can those 3 classes somehow return the same object? FWIW, WebKit has always returned a static node list. WebKit doesn't support the microdata and radio button features, presumably, and is presumably less than perfectly compatible with the Web for the others. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Fri, Jul 13, 2012 at 3:17 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jul 2012, Ryosuke Niwa wrote: According to http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection *HTMLCollection* returns the first element. This is for compat in the default case, I believe. *HTMLAllCollection* returns the first element or another HTMLAllCollection if there are multiple elements This is needed for IE compat. We can't use live NodeList or a regular HTMLCollection? *HTMLFormControlsCollection* returns the first element or RadioNodeList if there are multiple elements This is needed to support the radio button value feature. *HTMLOptionsCollection* returns the first element or live NodeList if there are multiple elements This is for compat, I believe. (We don't want to return just a node if there are many matching.) We can't return HTMLAllCollection or RadioNodeList here? Can those 3 classes somehow return the same object? FWIW, WebKit has always returned a static node list. WebKit doesn't support the microdata and radio button features, presumably, and is presumably less than perfectly compatible with the Web for the others. :-) I'm not certain if we're willing to change our behavior to match the spec. We haven't gotten any bug reports due to this behavior as far as I know, and following the spec introduces a significant code complexity. - Ryosuke
