Re: [whatwg] framesets
Brian, You have specified that your requirement is to prevent people from linking to or bookmarking individual pages inside of frames. Framesets do not satisfy that requirement. They make it a little more difficult, but they do not prevent it. Of course the frameset /by itself /doesn't satisfy that requirement. It permits us to meet the requirement with little code. Ian posted one, had-written just for you, which you dismissed without giving any reason. It's a nice, partial demo---side-by-side scrolling no node bookmarking. But no borders, no resizing, no horizontal scrolling within frames, it requires a separate html page for each node, c. So it would take a fair bit of time to see if a whole implementation of the spec could be built on it. So it does not answer the question: if framesets are as you claim not needed for the full spec, there should be lots of non-frameset sites which meet this spec as efficiently as ours does. /No-one has pointed to one./ Implementations of a part of our spec without frames, like Google docreader MSDN, require ten times as much javascript or more, javadoc and other major help sites still use framesets, c. Framesets suck because they combine both layout and embedding semantics into one syntax, which give them much less layout flexibility than using CSS. If that blocks a use case, by all means don't use a frameset for it. For this use, the above poses no problem at all. And if CSS were actually as efficient for this spec as framesets, surely some developers would have taken advantage of that by now. Anything you can do with framesets (except resizing), you can do with iframes and CSS. Not resizing as you say, and see above. However, there are lots of things you can do with iframes and CSS that you cannot do with framesets. Which is an argument for iframes, but is /not/ an argument against framesets, which remain useful. Framesets are a completely different language than HTML; Not a completely different language, just a different control. So what? you cannot use framesets and any other content elements in the same document. No need in this case. This means that you are forced to, for example, use a frame for the header of your page, which may cause a scrollbar to appear if you don't allocate enough space, rather than just putting the header in the page directly and using iframes to include the other pages. Not an issue for this use. Here's an application for framesets which is valid on previous versions of HTML, meets a need, is more efficient than known implemented alternatives for this use case, and does not suffer from any of the frameset deficiencies you have listed. Framesets remain useful, excluding them from HTML5 undermines support for those uses, and that weakens HTML5. PB
Re: [whatwg] framesets
So it does not answer the question: if framesets are as you claim not needed for the full spec, there should be lots of non-frameset sites which meet this spec as efficiently as ours does. Maybe there are not many sites because nobody wants this type of sites? I hate this type of documentation sites personally. And to me this use case looks built around the chosen implementation, while I prefers solutions built around solving the real need. If that blocks a use case, by all means don't use a frameset for it. For this use, the above poses no problem at all. And if CSS were actually as efficient for this spec as framesets, surely some developers would have taken advantage of that by now. Once again you assume that your spec is highly desired. Maybe it is not the case and so nobody bothered. … No need in this case. … Not an issue for this use. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? Here's an application for framesets which is valid on previous versions of HTML, Nobody forbids you from using previous versions of HTML. meets a need, is more efficient than known implemented alternatives for this use case, You have framed (pardon the pun) this use case this way and reject all other options. Once again—you can use HTML4.01 frameset document with HTML5 documents loaded to frames. This was suggested more than once. and does not suffer from any of the frameset deficiencies you have listed. How so? Framesets remain useful, excluding them from HTML5 undermines support for those uses, and that weakens HTML5. I'd argue that it strengthens HTML5. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
Ian Hickson i...@hixie.ch, 2009-10-14 03:41 +: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 2. Use legend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Use dt/dd, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. In terms of the Priority of Constituencies principle, it'd seem to me that between #2 and #3, #2 will -- in the long term -- ultimately have lower costs and difficulties for authors, though higher costs and difficulties for implementors in the short term. I would think a big red flag ought to go up for any proposed solution that we know will lead to introducing complicated and elaborate hacks into new content. For one thing, we know from experience that due to cargo-cult copy-and-paste authoring, such hacks have a tendency to live on in content for years after the need for them in widely used UAs has disappeared. http://www.w3.org/TR/html-design-principles/#priority-of-constituencies -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Wed, Oct 14, 2009 at 1:04 PM, Andrew Scherkus scher...@google.comwrote: We use a combination of in-memory and block-based caching for media resources. There is no guarantee whatsoever on what is loaded. There's a nice side benefit of allowing complete random access to the file if the server supports range request (in my opinion a must if you're working on an audio/video site, but that's a side issue). Indeed, we support that too. For http:// we don't support load at all and never reach NETWORK_LOADED. We're also baffled at what to report in our progress events because the numbers are seemingly useless in our context. Sometimes we'll cache the end of the file to grab some useful metadata, but we don't want to fire a progress event saying we've loaded the last bit of the file... We have the same issue, unsurprisingly. Currently our progress events are not very useful because we report the download position (although we do suppress progress events while we read metadata from the end of the file). According to the spec, however, progress events should report the *amount* of data downloaded, not the position within the resource. That's a bit more useful, although it's still unclear what to do when data is discarded from the cache and then re-downloaded. Being the only browser (I think?) that doesn't fire the load event we've ran into site compatibility issues. I believe a lot of web authors are used to tacking onload= into a tag and expecting it to work. I've reached out to web authors to educate them about using canplaytype() + oncanplay/oncanplaythrough as alternatives to user agent checking and onload. Good, thanks. We plan to stop firing the load event in the next (and all future) versions of Gecko, so we'll be doing that outreach too. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 14/10/2009 04:41, Ian Hickson wrote: On Tue, 29 Sep 2009, Dean Edwards wrote: It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- You can start using HTML5 except details which will look OK in some browsers but completely break others. ...and except forcanvas which will be slow or not work in IE for the forseeable future, and the drag and drop model's draggable attribute which will only work in new browsers, or the new controls which will look like text fields in legacy UAs, or... how isdetails different? The other things you mentioned don't work but don't break anything. Using details can potentially break entire pages. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) We have more than a dozen elements whose names would be appropriate here. Inventing entirely new elements to do the same thing again just to work around a very short-term problem is just silly. I don't think it is silly to prevent severe rendering problems in 30% of installed browsers. As far as I can see the options are as follows: 1. Drop support fordetails andfigure for now, revisit it later. 2. Uselegend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Usedt/dd, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. If we go with #3, I can always add a Best viewed with Firefox badge to my web sites. That will solve the problem. -dean
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Thu, 8 Oct 2009, Robert O'Callahan wrote: http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource In the resource fetch algorithm, after we reach the NETWORK_LOADED state in step 3 which indicates that all the data we need to play the resource is now available locally, we end the resource fetch algorithm. However, in Gecko we have a media cache which might discard blocks of media data after we've reached the NETWORK_LOADED state (to make room for data for other loading resources). This means we might have to start fetching the resource again later. The spec does not seem to allow for this. Do we need to change our behavior, or does the spec need to change to accommodate our behavior? I'd prefer not to change our behavior since I think to follow the spec we'd need to pin the entire resource permanently in the cache after we reached NETWORK_LOADED, which could be highly suboptimal in some situations. Step 2 says While the user agent might still need network access to obtain parts of the media resource, the user agent must remain on this step. It even has an example of a UA that discards video data. Another issue is that it's not completely clear to me what is meant by While the user agent might still need network access to obtain parts of the media resource What if there is data in the resource that we don't need in order to play through normally, but which might be needed in some special situations (e.g., enabling subtitles, or seeking using an index), and we optimize to not load that data unless/until we need it? In that case would we never reach NETWORK_LOADED? Correct. In general NETWORK_LOADED and the load event seem rather useless and dangerous IMHO. If you're playing a resource that doesn't fit in your cache then you'll certainly never reach NETWORK_LOADED, and since authors can't know the cache size they can never rely on load firing. And if you allow the cache discarding behavior I described above, authors can't rely on data actually being present locally even after load has fired. I suspect many authors will make invalid assumptions about load being sure to fire and about what load means if it does fire. Does anyone have any use cases that load actually solves? I'm happy to remove 'load'. It's mostly a holdover from the first cut at this API, where this wasn't thought through in much detail. On Fri, 9 Oct 2009, Robert O'Callahan wrote: Me too. I'm game if you are! So I propose: 1) Remove the NETWORK_LOADED state and load and loadend events from media elements. The resource fetch algorithm simply never transitions from step 2 to step 3. Done. NOTE: I've changed NETWORK_NO_SOURCE's value from 4 to 3! On Fri, 9 Oct 2009, Simon Pieters wrote: 'loadend' also fires after 'abort' and (when using the src attribute) 'error'. Should that stay as is, or also be removed? On Fri, 9 Oct 2009, Philip Jägenstedt wrote: Since we're going to contradict the progress events spec anyway, I would suggest dropping all 'loadend' events. They're just not very useful. I've left it in the other cases, since, well, Progress Events says to. But I'd be happy to drop loadend in all cases (including other Progress Events cases) if that makes sense. On Tue, 13 Oct 2009, Andrew Scherkus wrote: We're also baffled at what to report in our progress events because the numbers are seemingly useless in our context. Sometimes we'll cache the end of the file to grab some useful metadata, but we don't want to fire a progress event saying we've loaded the last bit of the file... On Wed, 14 Oct 2009, Robert O'Callahan wrote: We have the same issue, unsurprisingly. Currently our progress events are not very useful because we report the download position (although we do suppress progress events while we read metadata from the end of the file). According to the spec, however, progress events should report the *amount* of data downloaded, not the position within the resource. That's a bit more useful, although it's still unclear what to do when data is discarded from the cache and then re-downloaded. Ok, I've switched them back to regular Event events, though using the same event names. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Wed, Oct 14, 2009 at 05:41, Ian Hickson i...@hixie.ch wrote: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 2. Use legend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Use dt/dd, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. So what you'd expect is that #3 would take about 4 years to completely fix itself, and #2 would take about 5 years. With such a small difference, I'd just choose the best option in the long term. -- Remco
Re: [whatwg] Using Web Workers without external files
On Wed, 23 Sep 2009, Simon Pieters wrote: I'd like a way to use workers without having to use an external resource. This would allow easier testing, mashups, small standalone apps, and so forth. I agree that it makes sense to support this on the long run. However, for the short run, I think using eval() is sufficient. If people feel strongly about this, my proposal would be to use sicking's idea of just allowing data: URLs. Specifically, making step 3 of the Worker() constructor (not SharedWorker) allow data: URLs as a special case. That's an easy thing to do, and it's not like we'll ever use data: URLs in this context for something else. On Thu, 24 Sep 2009, Marius Gundersen wrote: What about a javascript: url, like the addressbar and links already accept? That wouldn't have quite the right semantics -- they'd be evaluated in the content of the original script (or in a blank execution context, dependeng on how we defined it), and then their return value would be executed... that's one level of indirection too far. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove [Supplemental] in Web Workers
On Wed, 23 Sep 2009, Simon Pieters wrote: DedicatedWorkerGlobalScope and SharedWorkerGlobalScope probably shouldn't have [Supplemental]. Yes, they should -- it means that their definitions are just globbed onto the definition of their ancestor, WorkerGlobalScope, as if there was one WorkerGlobalScope in dedicated workers and one in shared workers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] security exception not defined, used in Web Workers
On Wed, 23 Sep 2009, Simon Pieters wrote: If the origin of the resulting absolute URL is not the same as the origin of the script that invoked the constructor, then throw a security exception. says step 3 of the Worker constructor. I don't see security exception defined in HTML5. (HTML5 says in various places to raise a SECURITY_ERR exception.) Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Interface object vs constructor in Web Workers
On Fri, 25 Sep 2009, Simon Pieters wrote: http://www.whatwg.org/specs/web-workers/current-work/#interface-objects-and-constructors seems to say that there must be no interface object for Worker and SharedWorker, but the constructors are to be available, which doesn't make any sense since the constructor and the interface object are in fact the same object, unless I'm misunderstanding things. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Typo in Web Workers
On Mon, 28 Sep 2009, Simon Pieters wrote: WorkerUtils implement WindowTimers; should be WorkerUtils implements WindowTimers; Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers and addEventListener
On Tue, 29 Sep 2009, Zoltan Herczeg wrote: In WebKit implementation of MessagePort the addEventListener(message, ...) does not enable the transmitting of messages. All messages are actually discarded until a dummy function is assigned to onmessage. That is a bug. The port message queue is explicitly enabled during the creation of the dedicated worker (step 12). And in the normative text, it is not mentioned that addEventListener should also enable message transmitting. The normative text just says to fire an event; the DOM Events spec makes it clear that events can be handled using addEventListener()-added handlers. Anyway, my qestion is: - should addEventListener enable message transmitting? Yes. - Should it do it in all cases, or only when message is passed as the first argument It should only receive 'message' events if you say 'message' as the first argument. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers and addEventListener
On Tue, 29 Sep 2009, Drew Wilson wrote: The intent of the spec is fairly clear that addEventListener(message) should not start the message queue dispatch - only setting the onmessage attribute does that: The first time a MessagePort #messageport object's onmessage#handler-messageport-onmessage IDL attribute is set, the port's port message queue #port-message-queue must be enabled, as if the start() #dom-messageport-start method had been called. Yes, but the dedicated worker construction algorithm explicitly enables the message ports' message queues. In fact, the only reason for the existence of the MessagePort.start() method is to enable applications to start message queue dispatch when using addEventListener(). I don't have a strong opinion as to whether we should change the spec, though. I suspect not, given Anne's email. We should instead change the example in the workers spec to call start(). There's no start() to call, since there's no explicit pointer to the MessagePort in dedicated workers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Please always use utf-8 for Web Workers
On Fri, 25 Sep 2009, Simon Pieters wrote: Workers are new and seems very likely to be incompatible with existing scripts. So it is not subject to legacy content with legacy encodings. Therefore, we should be able to always use utf-8 for workers. Always using utf-8 is simpler to implement and test and encourages people to switch to utf-8 elsewhere. On Fri, 25 Sep 2009, Jonathan Cook wrote: The importScripts portion of the Web Workers API is compatible with existing scripts, but I'm all for more UTF-8 :) If the restriction is added to the spec, I'd want to know that a very clear error was going to be thrown explaining the problem. On Fri, 25 Sep 2009, Simon Pieters wrote: I'm not sure that throwing an error is a good idea. Would you throw an error when there's no declared encoding? That seems to be annoying for the common case of just using ASCII characters. Throwing an error when there is a declared encoding that is not utf-8 might work, but are there many scripts that have a declared encoding and are not utf-8? I think it is to just ignore any declared encoding and assume utf-8. If people are using non-ascii in another encoding, then they would notice by seeing that their text looks like garbage. Browsers could also log messages to their error consoles about encoding declarations declaring non-utf-8 and/or sequences of bytes that are not valid utf-8. On Fri, 25 Sep 2009, Drew Wilson wrote: Are you saying that if I load a script via a script tag in a web page, then load it via importScripts() in a worker, that the result of loading that script in those two cases should/could be different because of different decoding mechanisms? If that's what's being proposed, that seems bad. On Fri, 25 Sep 2009, Anne van Kesteren wrote: That could happen already if the script loaded via script did not have an encoding set and got it from script charset. On Fri, 25 Sep 2009, Drew Wilson wrote: Certainly. If I explicitly override the charset, then that seems like reasonable behavior. Having the default decoding vary between importScripts() and script seems bad, especially since you can't override charsets with importScripts(). On Fri, 25 Sep 2009, Anne van Kesteren wrote: It does not need to be overridden per se. If the document character encoding is different from UTF-8 then a script loaded through script will be decoded differently from a script loaded through importScripts() as well. On Mon, 28 Sep 2009, Michael Nordman wrote: Leaving legacy encodings behind would be a good thing if we can get away with it... jmho. Ok, I've mode workers assume UTF-8 always. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Wed, 14 Oct 2009 12:08:19 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 9 Oct 2009, Philip Jägenstedt wrote: Since we're going to contradict the progress events spec anyway, I would suggest dropping all 'loadend' events. They're just not very useful. I've left it in the other cases, since, well, Progress Events says to. But I'd be happy to drop loadend in all cases (including other Progress Events cases) if that makes sense. On Wed, 14 Oct 2009, Robert O'Callahan wrote: We have the same issue, unsurprisingly. Currently our progress events are not very useful because we report the download position (although we do suppress progress events while we read metadata from the end of the file). According to the spec, however, progress events should report the *amount* of data downloaded, not the position within the resource. That's a bit more useful, although it's still unclear what to do when data is discarded from the cache and then re-downloaded. Ok, I've switched them back to regular Event events, though using the same event names. We added loadend just to comply with Progress Events. Now that we fire simple events instead, please drop loadend again as it serves no purpose at all. I doubt any browser has yet shipped an implementation firing loadend, correct me if I'm wrong. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Wed, 14 Oct 2009 12:51:09 +0200, Philip Jägenstedt phil...@opera.com wrote: We added loadend just to comply with Progress Events. Now that we fire simple events instead, please drop loadend again as it serves no purpose at all. I doubt any browser has yet shipped an implementation firing loadend, correct me if I'm wrong. The loadend event is dispatched for XMLHttpRequest and that might be in Gecko I suppose. I'm not particularly attached to it though. I just added it for consistency with the media elements and the progress events specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 14 Oct 2009, at 11:06, Remco wrote: 2. Use legend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Use dt/dd, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. So what you'd expect is that #3 would take about 4 years to completely fix itself, and #2 would take about 5 years. With such a small difference, I'd just choose the best option in the long term. Option #2 affects every major browser currently on the market (i.e. it's broken) - I'm excluding betas. That's Opera, Firefox, IE, Safari Chrome. Option #3 only affects IE7 and below - which is 30+% of the market, but at the very least IE8 has it right - which means that (I would hope) future versions of IE won't have this bug. I'd be amazed if IE7 is flushed out of the major market share (20% since Firefox is around that mark) within 5 years (personally I'm expecting to be around for longer) - rather than amazed, going by the growth rates (of other browsers), I'm saying it won't happen. So to say that *all* the browsers that we currently have are going to be down to a insignificant market share, that we can sensibly use legend is going to much more than 5 years. http://en.wikipedia.org/wiki/Usage_share_of_web_browsers With that in mind, and having to choose the lesser of two evils (though semantically I know which I prefer), option #3 is the only sensible choice if you want authors to use these elements in a reasonable amount of time. Remy Sharp.
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Wed, 14 Oct 2009 12:58:17 +0200, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Oct 2009 12:51:09 +0200, Philip Jägenstedt phil...@opera.com wrote: We added loadend just to comply with Progress Events. Now that we fire simple events instead, please drop loadend again as it serves no purpose at all. I doubt any browser has yet shipped an implementation firing loadend, correct me if I'm wrong. The loadend event is dispatched for XMLHttpRequest and that might be in Gecko I suppose. I'm not particularly attached to it though. I just added it for consistency with the media elements and the progress events specification. I'm only talking about dropping it for media elements. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Microdata feedback
On Fri, 21 Aug 2009, Philip Jägenstedt wrote:
The spec says that properties can also themselves be groups of
name-value pairs, but this isn't exposed in a very convenient way in
the DOM API. The 'properties' DOM-property is a HTMLPropertyCollection
of all associated elements. Discovering if the item-property value is a
plain string or an item seems to require item.hasAttribute('item'),
which seems out of place when everything else has been so neatly
reflected.
This is now reflected on item.itemScope.
Also, the 'contents' DOM-property is always the item-property value
except in the case where the item-property is another item -- in that
case it is something random like .href or .textContent depending on the
element type. I think it would be better if the DOM-property were simply
called 'value' (the spec does talk about name-value pairs after all) and
corresponded more exactly to 'property value' [3]. Elements that have no
'property names' [4] should return null and otherwise elements with an
'item' attribute should return itself, although I don't think it should
be writable in that case. One might also/otherwise consider adding a
valueType DOM-property which could be 'string', 'item' or something
similar.
Interesting idea. I've renamed 'content' to 'itemValue', and made it
return null if there's no itemprop=, and the element itself if there's
an itemscope=.
One example [5] uses document.items[item].names but document.items isn't
defined anywhere. I assume this is an oversight and that it is
equivalent to document.getItems() Further, names is a member of
HTMLPropertyCollection, so document.items[item].properties.names is
probably intended instead of document.items[item].names. Assuming this
the example actually produces the output it claims to.
Fixed.
Shouldn't namedItem [6] be namedItems? Code like .namedItem().item(0)
would be quite confusing.
[6]
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-htmlpropertycollection-nameditem
I don't understand what this is referring to.
Also, RadioNodeList should be PropertyNodeList.
Fixed.
I think many will wonder why item and itemprop can't be given on a
single element for compactness:
span item=org.example.fruit itemprop=org.example.nameApple/spans and
span item=org.example.fruit itemprop=org.example.nameOrange/spans
don't compare well.
Modulo the changes to the syntax (s/item=/itemscope itemtype=/g), this is
allowed -- but it means the same as this:
span itemprop=org.example.name itemscope itemtype=org.example.fruit...
...which is to say, it's giving a property whose value is itself an item.
On Sun, 23 Aug 2009, Eduard Pascual wrote:
On Sat, Aug 22, 2009 at 11:51 PM, Ian Hicksoni...@hixie.ch wrote:
Based on some of the feedback on Microdata recently, e.g.:
� http://www.jenitennison.com/blog/node/124
...and a number of e-mails sent to this list and the W3C lists, I am
going to try some tweaks to the Microdata syntax. Google has kindly
offered to provide usability testing resources so that we can try a
variety of different syntaxes and see which one is easiest for authors
to understand.
If anyone has any concrete syntax ideas that they would like me to
consider, please let me know. There's a (pretty low) limit to how many
syntaxes we can perform usability tests on, though, so I won't be able
to test every idea.
This would be more than just tweaking the syntax, but I think
appropriate to bring forth my CRDF proposal as a suggestion for an
alternative to Microdata.
I considered testing this, as well as RDFa, but due to time constraints we
ended up only being able to test a few changes, so I concentrated
specifically on microdata variants.
On Tue, 25 Aug 2009, Philip Jägenstedt wrote:
There's something like an inverse relationship between simplicity of the
syntax and complexity of the resulting markup, the best balance point
isn't clear (to me at least). Perhaps option 3 is better, never allowing
item+itemprop on the same element.
That would preclude being able to make trees.
Given that flat items like vcard/vevent are likely to be the most
common use case I think we should optimize for that. Child items can
be created by using a predefined item property:
itemprop=com.example.childtype item. The value of that property
would then be the first item in tree-order (or all items in the
subtree, not sure). This way, items would have better copy-paste
resilience as the whole item element could be made into a top-level
item simply by moving it, without meddling with the itemprop.
That sounds kinda confusing...
More confusing than item+itemprop on the same element? In many cases the
property value is the contained text, having it be the contained item
node(s) doesn't seem much stranger.
Based on the studies Google did, I'm not convinced that people will
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Wed, 14 Oct 2009, Philip J�genstedt wrote: On Wed, 14 Oct 2009 12:08:19 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 9 Oct 2009, Philip J�genstedt wrote: Since we're going to contradict the progress events spec anyway, I would suggest dropping all 'loadend' events. They're just not very useful. I've left it in the other cases, since, well, Progress Events says to. But I'd be happy to drop loadend in all cases (including other Progress Events cases) if that makes sense. On Wed, 14 Oct 2009, Robert O'Callahan wrote: We have the same issue, unsurprisingly. Currently our progress events are not very useful because we report the download position (although we do suppress progress events while we read metadata from the end of the file). According to the spec, however, progress events should report the *amount* of data downloaded, not the position within the resource. That's a bit more useful, although it's still unclear what to do when data is discarded from the cache and then re-downloaded. Ok, I've switched them back to regular Event events, though using the same event names. We added loadend just to comply with Progress Events. Now that we fire simple events instead, please drop loadend again as it serves no purpose at all. I doubt any browser has yet shipped an implementation firing loadend, correct me if I'm wrong. Ok, removed loadend from HTML5 altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Transparent Content
From: Ian Hickson Anyway, Perhaps this will do? If a transparent element were to be removed but its descendants were kept as they are, the content should remain conformant. Or: Any transparent content should be conformant as if its transparent containing element did not exist. Unfortunately both of these can be interpreted as saying that the element and all its children disappear -- kept as they are implies kept as children of the element; [parent] element did not exist implies the kids aren't in the tree, etc. But again, perhaps the added example makes things clear enough. Just trying to help. Your help is much appreciated. I'm glad the example helps. I'll give it one more go. ;-) Perhaps you could leave the existing sentence, but add: In short; a transparent element must have the same content model as its parent. Or something to that effect? Evert
Re: [whatwg] Transparent Content
On Wed, Oct 14, 2009 at 8:17 AM, Yuvalik Webdesign postmas...@yuvalik.org wrote: From: Ian Hickson Anyway, Perhaps this will do? If a transparent element were to be removed but its descendants were kept as they are, the content should remain conformant. Or: Any transparent content should be conformant as if its transparent containing element did not exist. Unfortunately both of these can be interpreted as saying that the element and all its children disappear -- kept as they are implies kept as children of the element; [parent] element did not exist implies the kids aren't in the tree, etc. But again, perhaps the added example makes things clear enough. Just trying to help. Your help is much appreciated. I'm glad the example helps. I'll give it one more go. ;-) Perhaps you could leave the existing sentence, but add: In short; a transparent element must have the same content model as its parent. Or something to that effect? That's still not accurate, though. ^_^ I mean, it's *correct*, but it's not a summarization of the existing sentence (which is implied by in short). Ian pointed out how a transparent element can have children that would match the content model of the parent, but that wouldn't be correct if simply inserted into the parent (the example with unique). ~TJ
Re: [whatwg] Transparent Content
From: Tab Atkins Jr. Perhaps you could leave the existing sentence, but add: In short; a transparent element must have the same content model as its parent. Or something to that effect? That's still not accurate, though. ^_^ I mean, it's *correct*, but it's not a summarization of the existing sentence (which is implied by in short). Ian pointed out how a transparent element can have children that would match the content model of the parent, but that wouldn't be correct if simply inserted into the parent (the example with unique). Hmm, yes. Oh well. I give up. It's not that important anyway. And with the added example I am sure it will be ok. Evert
Re: [whatwg] fieldset (was: The legend element)
Hixie wrote: Then it might be nice to clarify this with a few words in the spec, as The fieldset element represents a set of form controls optionally grouped under a common name can be read as implying structuring and thus accessibility matters. The element does add structure and help with accessibility, but that doesn't mean it's always necessary. I just had a thought (that I sanity-checked in IRC)... Perhaps fieldset should be a sectioning root? It feels like it's a similar kind of grouping element to blockquote and td in that, while it might well contain headings, you probably wouldn't want those headings to contribute to the overall outline of the document. What do you think? -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] fieldset (was: The legend element)
On Wed, Oct 14, 2009 at 10:32 AM, Jeremy Keith jer...@adactio.com wrote: Hixie wrote: Then it might be nice to clarify this with a few words in the spec, as The fieldset element represents a set of form controls optionally grouped under a common name can be read as implying structuring and thus accessibility matters. The element does add structure and help with accessibility, but that doesn't mean it's always necessary. I just had a thought (that I sanity-checked in IRC)... Perhaps fieldset should be a sectioning root? It feels like it's a similar kind of grouping element to blockquote and td in that, while it might well contain headings, you probably wouldn't want those headings to contribute to the overall outline of the document. What do you think? Since I was the one it was sanity-checked against, +1 to this suggestion. I sometimes use headings to label individual inputs in a form, and I don't particularly want to expose these in the page outline. A rider suggestion: expose legend in the page outline as the heading for the fieldset. (I don't *think* this currently happens in the outline algorithm, but whatwg.org is down atm so I can't check.) ~TJ
Re: [whatwg] framesets
Rimantas, Maybe there are not many sites because nobody wants this type of sites? You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. The full use case is treeview database maintenance. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever. I hate this type of documentation sites personally. Fine, you've no need for website maintenance of data-driven trees. That's not a rationale for excluding framesets from HTML5. And to me this use case looks built around the chosen implementation, Wrong. Frameset was chosen because it provides the most efficient available implementaiton. while I prefers solutions built around solving the real need. Which this is. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? May I have rational responses please? This is not a request for a new feature. I want HTML5 to continue support for useful HTML. Nobody forbids you from using previous versions of HTML. Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. PB - Rimantas Liubertas wrote: So it does not answer the question: if framesets are as you claim not needed for the full spec, there should be lots of non-frameset sites which meet this spec as efficiently as ours does. Maybe there are not many sites because nobody wants this type of sites? I hate this type of documentation sites personally. And to me this use case looks built around the chosen implementation, while I prefers solutions built around solving the real need. If that blocks a use case, by all means don't use a frameset for it. For this use, the above poses no problem at all. And if CSS were actually as efficient for this spec as framesets, surely some developers would have taken advantage of that by now. Once again you assume that your spec is highly desired. Maybe it is not the case and so nobody bothered. … No need in this case. … Not an issue for this use. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? Here's an application for framesets which is valid on previous versions of HTML, Nobody forbids you from using previous versions of HTML. meets a need, is more efficient than known implemented alternatives for this use case, You have framed (pardon the pun) this use case this way and reject all other options. Once again—you can use HTML4.01 frameset document with HTML5 documents loaded to frames. This was suggested more than once. and does not suffer from any of the frameset deficiencies you have listed. How so? Framesets remain useful, excluding them from HTML5 undermines support for those uses, and that weakens HTML5. I'd argue that it strengthens HTML5. Regards, Rimantas -- http://rimantas.com/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09 06:33:00
Re: [whatwg] framesets
On Wed, Oct 14, 2009 at 11:56 AM, Peter Brawley p...@artfulsoftware.com wrote: Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. The spec requires all browsers to support framesets. Look: http://www.w3.org/TR/html5/obsolete.html#frames Notice that this is contained in a section labeled Requirements for implementations. Also note that the section is full of requirements saying the user agent must. An implementation that does not support frames is non-conforming. HTML5 requires frame support in user agents. This has been stated a number of times before; what part is unclear? The *only* effect on you if you use frames is that your pages will not validate as HTML5. They will still work perfectly. Their status as non-conforming but specified is basically HTML5's analogue to HTML4's permitted but with their own DTD that we discourage authors from using. Nothing has changed between HTML4 and HTML5 for you, as an author, except that validators will complain. HTML5 will probably lead to even more consistent frameset support across user agents, if anything.
Re: [whatwg] framesets
Maybe there are not many sites because nobody wants this type of sites? You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. Of course Java developers want access to documentation. I am not sure if they want frameset though. The full use case is treeview database maintenance. Server side should not be even mentioned in this case. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever. Tree logic requires a bit of effort with table design and SQL, and is very easy in HTML and PHP/Ruby/whatever. … while I prefers solutions built around solving the real need. Which this is. Nope. I guess real need is something along the lines provide access to documentation online or something like that. … Nobody forbids you from using previous versions of HTML. Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. I would like to see that but not going to happen. Browsers will support HTML4 for decades to come. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
On 14 Oct 2009, at 17:12, Rimantas Liubertas wrote: Maybe there are not many sites because nobody wants this type of sites? You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. Of course Java developers want access to documentation. I am not sure if they want frameset though. Actually, the Java documentation is fantastic, largely because of the way it uses frames. It's quite widely commended as one of the best things Java has introduced and the concept has been copied by many other implementations - including Ruby on Rails (http://api.rubyonrails.org/ ). By contrast, MSDN documentation is a really horrific experience and I've always wished they'd just move to frames. The key point here is really to avoid basing these decisions on personal preference because clearly in this case reasonable people can and do disagree about that preference. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 628 353 032 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] framesets
On Wed, Oct 14, 2009 at 8:56 AM, Peter Brawley p...@artfulsoftware.com wrote: Nobody forbids you from using previous versions of HTML. Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. As a browser developer, and as someone that would have a lot of say in the decision weather firefox would drop support for frameset, I can tell you that you are wrong on this point. We don't decide to drop support for features based on if they are in any given specification or not. We base the decision on if the feature is used in real world web pages or not. For example I'd love to drop support for DOM Mutation Events, even though they are in a spec. I don't care if they are in a spec or not. However I can't currently drop support for them since too many sites use them. / Jonas
Re: [whatwg] Restarting the media element resource fetch algorithm after load event
On Wed, Oct 14, 2009 at 11:51 PM, Philip Jägenstedt phil...@opera.comwrote: We added loadend just to comply with Progress Events. Now that we fire simple events instead, please drop loadend again as it serves no purpose at all. I doubt any browser has yet shipped an implementation firing loadend, correct me if I'm wrong. We have never fired loadend. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Issues with Web Sockets API
13.10.2009, в 4:11, Ian Hickson написал(а): Is this meant to mimic some behavior that existing clients have for HTTP already? Yes, as it says, the idea is for UAs to send the same headers they would send if the protocol had been HTTP. For HTTP, this depends on authentication scheme in use. For Basic and Digest authentication in particular, clients are allowed to make certain assumptions about protection spaces: A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. I don't think the Web Sockets protocol is sufficiently similar to HTTP to defer to RFC 2617 or other HTTP specs here. Also, implementing just support the same authentication mechanisms you do for HTTP is a tall order, since HTTP back-ends don't (always?) expose the necessary APIs for encryption. If /code/, interpreted as ASCII, is 401, then let /mode/ be _authenticate_. Otherwise, fail the Web Socket connection and abort these steps. 407 (proxy authenticate) also likely needs to be supported. Proxies wouldn't work with WebSockets in general. Could you please elaborate? I thought there was a setup that could work with most deployed HTTPS proxies - one could run WebSockets server on port 443. A feature that doesn't work behind proxies suddenly makes a lot less sense - one could use it to control a toy railroad over intranet, but do other use cases survive? Some authentication schemes (e.g. NTLM) work on connection basis, so I don't think that closing the connection right after receiving a challenge can work with them. Yeah, that's quite possible. Is this something you plan to correct in the spec? If practical uses of Web Sockets are all going to be over SSL (for proxy compatibility reasons), then even Basic auth seems ok for many cases, but NTLM still has important benefits over it. The primary benefit I'm aware of is that passwords don't need to be stored on the server. - WBR, Alexey Proskuryakov
Re: [whatwg] framesets
PB, No matter what display method you use, it sounds like an important requirement is to keep users from ever viewing the HTML of a row other than from your display app/page. It seems to me to achieve this you must not use URIs alone to fetch the row view that goes in the row's frame, because it's likely that the URI could be observed by a bad guy. If someone types (somewhat fanciful example URLs here) wget http://10.0.0.1/artfuldata/main/table7/row432 or wget http://10.0.0.1/artfuldata/showRow?432 or whatever form of URL you use, and gets one of your row's pages, isn't that a problem? Otherwise, it seems that for a browser to be found compliant with HTML5 it must render framesets in accordance with HTML5, so in that practical sense you can still use framesets. On Wed, Oct 14, 2009 at 8:56 AM, Peter Brawley p...@artfulsoftware.com wrote: Rimantas, Maybe there are not many sites because nobody wants this type of sites? You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. The full use case is treeview database maintenance. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever. I hate this type of documentation sites personally. Fine, you've no need for website maintenance of data-driven trees. That's not a rationale for excluding framesets from HTML5. And to me this use case looks built around the chosen implementation, Wrong. Frameset was chosen because it provides the most efficient available implementaiton. while I prefers solutions built around solving the real need. Which this is. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? May I have rational responses please? This is not a request for a new feature. I want HTML5 to continue support for useful HTML. Nobody forbids you from using previous versions of HTML. Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. PB - Rimantas Liubertas wrote: So it does not answer the question: if framesets are as you claim not needed for the full spec, there should be lots of non-frameset sites which meet this spec as efficiently as ours does. Maybe there are not many sites because nobody wants this type of sites? I hate this type of documentation sites personally. And to me this use case looks built around the chosen implementation, while I prefers solutions built around solving the real need. If that blocks a use case, by all means don't use a frameset for it. For this use, the above poses no problem at all. And if CSS were actually as efficient for this spec as framesets, surely some developers would have taken advantage of that by now. Once again you assume that your spec is highly desired. Maybe it is not the case and so nobody bothered. … No need in this case. … Not an issue for this use. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? Here's an application for framesets which is valid on previous versions of HTML, Nobody forbids you from using previous versions of HTML. meets a need, is more efficient than known implemented alternatives for this use case, You have framed (pardon the pun) this use case this way and reject all other options. Once again—you can use HTML4.01 frameset document with HTML5 documents loaded to frames. This was suggested more than once. and does not suffer from any of the frameset deficiencies you have listed. How so? Framesets remain useful, excluding them from HTML5 undermines support for those uses, and that weakens HTML5. I'd argue that it strengthens HTML5. Regards, Rimantas -- http://rimantas.com/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09 06:33:00
Re: [whatwg] framesets
On Wed, Oct 14, 2009 at 4:38 PM, Michael Enright michael.enri...@gmail.com wrote: No matter what display method you use, it sounds like an important requirement is to keep users from ever viewing the HTML of a row other than from your display app/page. It seems to me to achieve this you must not use URIs alone to fetch the row view that goes in the row's frame, because it's likely that the URI could be observed by a bad guy. The page linked to earlier, http://www.artfulsoftware.com/infotree/mysqlquerytree.php, seems to use some kind of temporary URL that prevents this.
Re: [whatwg] framesets
Aryeh Gregor schrieb: On Wed, Oct 14, 2009 at 11:56 AM, Peter Brawley p...@artfulsoftware.com wrote: Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. The spec requires all browsers to support framesets. Look: http://www.w3.org/TR/html5/obsolete.html#frames Notice that this is contained in a section labeled Requirements for implementations. Also note that the section is full of requirements saying the user agent must. An implementation that does not support frames is non-conforming. HTML5 requires frame support in user agents. This has been stated a number of times before; what part is unclear? The *only* effect on you if you use frames is that your pages will not validate as HTML5. Just for being nitpickinig: This only applies to the frameset document, which will validate as HTML4 Frameset. The pages contained will validate as HTML5 (if properly coded, of course). I assume the validator does not even recognize the fact that a document is part of a frameset.
