Re: [whatwg] Browser Bundled Javascript Repository
Some quick feedback before I heed Ian's advice and try to formalize things a little more. As a browser vendor (or at least someone working for one, specifically on script-loading), I would definitely be interested in something like this. However there are some hard problems to be solved: I looked through the mailing list and I take it you're from Mozilla. Correct me if I'm wrong. =) 1. How do we choose which libraries to pre-package? I'd rather not be in charge of ruling which libraries are popular enough or cool enough to warrant inclusion. It'd be very nice if the library cache were populated dynamically as the user used the web. Yes this point did come up. I believe that the cache can be grown dynamically, but I don't think that the cache could be reliably used without some indication or opt-in from the html (and thus the developer or some automated process). Files can be compared with each other very quickly, and SHA hashes even quicker, to determine that indeed the same content is being sent from multiple URLs, thus allowing potential for the cache to grow dynamically with frequently encountered content. But, again, I think the problem is then on the developer to opt-in to the service, otherwise the cache is just a speculation. 2. How do we deal with identifying libraries. As Aaron Boodman pointed out, SHA hashes means that you can't make upgrades for security problems etc. I still don't see this as an issue. As long as it is a SHA hash of the content, then its the content that matters. If a developer is using a script with a security problem then they should change their script. At this point a browser could go the extra mile and attempt to fix it for them by updating the script but thats another speculation. The idea of canonical names could run into problems though. 3. Compat when the browser doesn't have a library cached. A solution that includes using a different uri for browsers that do support caching than browsers that don't is scary since there is a big risk that the author will forget to update one but not the other. Yes, I do see this as a problem. I gave a response to this before, but I do still see this as being a potential headache point. Tools can easily solve this but thats not a perfect solution. I haven't come up with a good solution to this, but I do have some ideas. I believe all these problems are solvable, but they do need to be solved before considering inclusion in any spec. I'm also not convinced this needs to be included in the HTML5 spec, but that might depend on what the ultimate solution looks like. I agree again. I concluded this feature makes the most sense for a restricted environment, such as developing mobile web apps. Those developers are already faced with some different conditions, and I think iPhone web development even has some custom syntax. A feature like this could make a much bigger impact in that kind of environment where it could gain traction. / Jonas Thanks for the feedback Jonas. - Joe
Re: [whatwg] HTML 5 video tag questions
On Mon, 15 Jun 2009 jjcogliati-wha...@yahoo.com wrote: Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere like: | Authors may provide multiple source elements to provide different | codecs for different user agents. That section no longer exists. On Tue, 16 Jun 2009, Sam Dutton wrote: Could multiple source elements also be used to provide different bit-rate sources (or even alternative versions, e.g. different languages) as well as different codecs, something like the HTTP streaming playlist idea? On Tue, 16 Jun 2009, Benjamin M. Schwartz wrote: If the browser decides that a video is too high resolution and cannot be played on this system, then why can't it fall through to a lower-resolution copy if one exists? The user agent is allowed to skip past a video file it deems unsuitable, but as currently written, the algorithm precludes the user agent skipping past a resource based on the presence or absence of a further resource that it deems superior. On Tue, 16 Jun 2009, David Singer wrote: [...] there are media queries, and I have posted a couple of times that we should considering allowing source selection based on accessibility needs. we should probably also make it possible to select on language, it's a common need. Localisation in general of HTML isn't supported at the moment; it's assumed that this will be done server-side. (I don't see why we'd support localisation of video and audio media when we don't support localisation of text or images yet). On Fri, 10 Jul 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? When would you fall back? For example, while parsing, would you fall back in between the video element being parsed and the first source element being parsed? The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. On Fri, 10 Jul 2009, Jeff Walden wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. In practice, as people keep pointing out to me, it's only Apple that supports video but doesn't support Theora. If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback for video-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support inside video), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. On Fri, 10 Jul 2009, Jeff Walden wrote: (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) I also think that would make more sense. Right now if a site wants to publish Ogg-only with Cortado as the fallback, they have to use scripting to make it work in Safari. Not supporting Safari would be an effective way of pressuring Apple. And if a site wants to publish H.264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. We presumably don't want to make the use of uncumbered codecs easier. Sites might want to do this even if there were an agreed-upon common codec that simply didn't meet their needs. So a common codec won't completely eliminate this issue. I can't see any advantage to the current design. Sanity and simplicity in implementation is the main advantage. With object, fallback proved to be a huge source of bugs for years. On Sat, 11 Jul 2009, Maciej Stachowiak wrote: There is likely an upper bound set by the maximum possible expiration date of any patents applying to any of the viable candidates. It's just that we'd like to reach agreement well before then. On Sat, 11 Jul 2009, Gregory Maxwell wrote: Not really, at some point well before then the argument will shift to a newer clearly superior to H.264 encumbered format. I would expect that H.264 would spend a
Re: [whatwg] input type=url allow URLs without http:// prefix
On Sun, Jul 12, 2009 at 3:48 PM, Kornel Lesinskikor...@geekhood.net wrote: On Sun, 12 Jul 2009 09:46:19 +0100, Bruce Lawson bru...@opera.com wrote: As it's very common for people to drop the http:// prefix on advertising, business cards etc (and who amongst us reads out the prefix when reading a URL on the phone?) I'd like to suggest that input type=url allows the http:// prefix to be optional on input and, if ommitted, be assumed when parsing. The spec explicitly allows that actual value seen and edited by the user in the interface is different from DOM value of the input, so browsers are free to prepend http:// automatically (and IMHO should – DSK-253195). To make this less ambiguous I would prefer that we talk about making it optional to specify a protocol or scheme name (personal preference for protocol) rather than http:// specifically. While http will be the most common protocol by far it is not the only possibility. I'm wary of automagically prepending values if it is not clear what has been added by the user agent compared to what has been added by the user. Thoughts of end users complaining that the information the site owner has on record is not what was entered without a clear log of the change spring to mind. Might sound far-fetched but I'm guessing most of us have heard weirder complaints. I have no problems with the idea though, I just think there needs to be a mechanism for highlighting the change to the user rather than this being hidden in the DOM. Regards, Ian Pouncey.
Re: [whatwg] HTML 5 video tag questions
On Jul 12, 2009, at 11:20 PM, Ian Hickson wrote: The design of video from the ground up is based on the idea that in browsers that support the element, the API will be used. If we change this assumption, then the entire design of the element would have to be reconsidered -- in particular, I think we would need to find a way to avoid people having to implement the script side twice, in such a scenario. We don't get a consistent design if we change the assumptions at the slightest provocation. In practice I don't think that the assumption is wrong on the long term, though it may be tested on the short term. video supports fallback to content that almost certainly has a very different API, in browsers that don't support video at all. I'm not sure why it would require major changes in the design to do such fallback in browsers that support video, but not the requested codec. It's true that it may be necessary to have multiple paths in your script if you use video that way. But you have to do that anyway, if you want to support browsers that don't have video at all. And in the case where you just want to embed a video using the best mechanism available, without scripting, the current design makes things harder. I think this argument holds up even if there is an agreed baseline - not everyone may want to use it, especially as the state of the art in video compression improves and higher resolution videos become more popular. I don't think this is an urgent issue, because we probably still have time to change. But I think the spec took the wrong path here and your argument above is not very persuasive. Regards, Maciej
Re: [whatwg] input type=url allow URLs without http:// prefix
On Sun, 12 Jul 2009 15:48:51 +0100, Kornel Lesinski kor...@geekhood.net wrote: On Sun, 12 Jul 2009 09:46:19 +0100, Bruce Lawson bru...@opera.com wrote: I'd like to suggest that input type=url allows the http:// prefix to be optional on input and, if ommitted, be assumed when parsing. The spec explicitly allows that actual value seen and edited by the user in the interface is different from DOM value of the input, so browsers are free to prepend http:// automatically (and IMHO should – DSK-253195). Excellent. And, while I don't doubt you at all, I'm abashed that I missed that nuance, especially as it'#s explicitly allowed? Where would I find that in the spec? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] HTML 5 video tag questions
On 12.7.09 23:20, Ian Hickson wrote: If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback forvideo-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support insidevideo), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. I'm fine doing this for myself: partly because it's pressure on Apple; perhaps mostly because I choose to make embedding videos that I can watch in-browser easy for myself, and because I don't particularly care if some portions of my audience are unable to see such videos and also choose not to download a browser that will display them (fallback content provides a download link -- I haven't made the effort to handle Safari4-sans-XiphQT yet, see supra). That said, my position will be uncommon, and I'm not particularly interested in making use of video right now harder for those who don't share it -- even if it comes at the expense of added pressure on Apple. Jeff
Re: [whatwg] Serving up Theora video in the real world
On Mon, 13 Jul 2009 00:00:20 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Jul 12, 2009 at 10:34 AM, Philip Jägenstedt phil...@opera.comwrote: Not that I except this discussion to go anywhere, but out of curiosity I checked how Firefox/Safari/Chrome actually implement canPlayType: http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support Firefox is conservative and honest (except maybe for audio/wav; codecs=0, what could you do with the RIFF DATA chunk?) Wave codec 0 means unknown codec, so we return maybe, but we should actually return no since in practice we refuse to play a file with 0 in the format field. We'll fix that. Safari gets maybe/probably backwards compared to what the spec suggests. Chrome seems to ignore the codecs parameter, claiming probably even for bogus codecs. Authors obviously can't trust the distinction between maybe and probably to any extent. Please file bugs against those browsers --- especially Chrome, since they haven't shipped video support yet. It's not hard to implement this right, these issues reflect sloppy development more than a fundamental problem IMHO. I agree that this isn't hard (even when using platform media frameworks), I'm only arguing that it isn't useful. However, both Mozilla and Apple representatives think differently, so I will not bother with this issue any more and simply implement it per spec as written. Also, I've reported bugs on Safari and Chrome (I think, neither give confirmation that the report has been sent successfully!) -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Fullscreenable attribute.
On Tue, 16 Jun 2009, Alpha Omega wrote: I think it would be useful to add fullscreenable (or more refined name) attribute to arbitrary element, so users could be able to full-screen DOM subtrees, that document author marked as fullscreenable. Usage: User choses area that he wants to fullscreen, peforms UA-specific action there(go to fullscreen in context menu in desktop browsers, or gesture on mobile devices for example), UA goes up in DOM tree until it founds fullscreenable attribute, and then fullscreens this subtree. If fullscreenable attribute is not found, then it is UA authors decision what to do - for example fullscreen entire page. Use case: Not only solves problem with video tag, but also useful for mobile UAs (users could use it to zoom to author defined parts, on pages with complex layouts.), and for interactive webapps in general IMHO. I think this would be an interesting idea. I haven't any idea what the UI would look like though. I recommend approaching vendors directly and getting their input and experimental implementations, as described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
On Sun, Jul 12, 2009 at 11:20 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, 10 Jul 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? When would you fall back? For example, while parsing, would you fall back in between the video element being parsed and the first source element being parsed? You could display the fallback once you've reached the /video and not found an acceptable source. Technically it'd be when you pop the video element off the stack of open elements. I don't even think it'd be hard to pull down all sources and check that none of them are supported before displaying the fallback if types aren't specified on the source element. The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. While object has had a very poor implementation story, I don't think this was a big reason for that. Robert O'Callahan, Boris Zbarsky and other gecko layout folks can answer this better, but at least in gecko I don't think this part of object was particularly hard to implement correctly once we actually tried. Has any browser vendor argued against displaying the fallback due to high implementation burden? / Jonas
Re: [whatwg] Fullscreenable attribute.
On 13/7/09 11:06, Ian Hickson wrote: On Tue, 16 Jun 2009, Alpha Omega wrote: I think it would be useful to add fullscreenable (or more refined name) attribute to arbitrary element, so users could be able to full-screen DOM subtrees, that document author marked as fullscreenable. Usage: User choses area that he wants to fullscreen, peforms UA-specific action there(go to fullscreen in context menu in desktop browsers, or gesture on mobile devices for example), UA goes up in DOM tree until it founds fullscreenable attribute, and then fullscreens this subtree. If fullscreenable attribute is not found, then it is UA authors decision what to do - for example fullscreen entire page. Should UAs always put users in control of this? ie. everything in principle is fullscreenable, but this indicator would be a strong hint that this chunk of content makes special sense to be treated in this manner. Use case: Not only solves problem withvideo tag, but also useful for mobile UAs (users could use it to zoom to author defined parts, on pages with complex layouts.), and for interactive webapps in general IMHO. I think this would be an interesting idea. I haven't any idea what the UI would look like though. I recommend approaching vendors directly and getting their input and experimental implementations, as described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F I like the idea of being able to go full-screen. I'd encourage talking to Web accessibility folk before going to far with a proposal / implementation... cheers, Dan
Re: [whatwg] Storage Events for a Specific Storage Area
On Wed, 17 Jun 2009, Joseph Pecoraro wrote:
The storage event [1] fires for both sessionStorage and localStorage.
To me, this means if you only want to interact with localStorage you
will have to manually ensure that it is the storage area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea === localStorage ) {
// ...
}
}
Was there any discussion about creating events specific to the storage
object, or should that already be possible? I've been playing around
with WebKit's Storage implementation, and the following (understandably)
is not possible:
localStorage.addEventListener
undefined
Is there any way to listen to events for a single specific storage area
or is the previously mentioned approach preferred?
We could make Storage into an EventTarget and also fire events on there,
sure. As Jeremy said, this is something that might best be done in the
next version; we're still trying to get the current features implemented
in a stable and consistent fashion as it is.
In general, though, I don't think it's critical, since you can easily work
around it by checking which was changed based on the event data.
(I agree that your proposal would have made more sense. I'm sorry my
learning experiences have such a detrimental effect on the Web! :-) )
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] editorial ambiguity in definition of nav?
On Thu, 18 Jun 2009, Bruce Lawson wrote: Spec says The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-nav-element Primary navigation blocks is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (primary navigation) and within-page links, eg a table of contents which many would term secondary nav. Because of the use of the phrase primary navigation block in the spec, a developer may think that her secondary nav should not use a nav element. Suggest rewording along the lines of only sections that consist of blocks whose primary purpose is navigation around the page or within the site are appropriate for the nav element, so - for example - lists of links to sponsors/ advertisers would not be marked up as nav elements. I fixed this by just changing primary to major. I've also added an example of secondary navigation using nav. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=url allow URLs without http:// prefix
On 13 Jul 2009, at 08:52, Bruce Lawson wrote: I'd like to suggest that input type=url allows the http:// prefix to be optional on input and, if ommitted, be assumed when parsing. The spec explicitly allows that actual value seen and edited by the user in the interface is different from DOM value of the input, so browsers are free to prepend http:// automatically (and IMHO should – DSK-253195). Excellent. And, while I don't doubt you at all, I'm abashed that I missed that nuance, especially as it'#s explicitly allowed? Where would I find that in the spec? The URL state section says that value in DOM may be different from value in the user interface: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#url-state The example difference given in the spec is URL-escaping, but in my understanding, it should allow to prepending of protocol as well (I admit that last bit is not stated explicitly). -- regards, Kornel
Re: [whatwg] Nested list
On Fri, 03 Jul 2009 00:05:09 +0200, Ryosuke Niwa rn...@google.com wrote:
Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
nested OL or UL without LI. See
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2 In fact, the
nested list example is marked deprecated. But in practice, all major
user agents produce nested list when execCommand(Indent...) is
executed.
I think this is a bug in execCommand('indent') and should be fixed in
browsers.
The spec doesn't seem to list 'indent' at all. It would be helpful if it
was specified.
Is there any chance we can standardize nested lists, and in
particular, what UA produce?
For example, all major browsers (Firefox, IE, WebKit) produce
slightly different versions of HTML when indenting item 2 in the
following HTML (assume it's content-editable):
ol
ol id=u1li id=i1item 1/li/ol
li id=i2item 2/li
ol id=u3li id=i3item 3/li/ol
/ol
In particular, many UA remove arbitrary id attributes.
Best regards,
Ryosuke Niwa
rn...@google.com
--
Simon Pieters
Opera Software
Re: [whatwg] Nested list
On 13/07/2009 12:01, Simon Pieters sim...@opera.com wrote:
I think this is a bug in execCommand('indent') and should be fixed in
browsers.
As someone who has gone to a great deal of effort to get HTML lists working
in an editor really well, I'd definitely agree. However, almost no editors
get this right for some reason. It's been quite a while since I tested but I
believe even Frontpage and Dreamweaver got it wrong at the time.
It does introduce complexities when you try to indent list items more than
one level deeper than it's parent, but semantically that really doesn't make
sense anyway. You can make it work by adding a new list item but with
list-style-type: none specified.
Regards,
Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 200 182 x481 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] Using em for Meta-Content
On Thu, 18 Jun 2009, Smylers wrote: HTML 5 currently defines em as being for stress emphasis of its contents, noting that: The placement of emphasis changes the meaning of the sentence. The element thus forms an integral part of the content. -- http://www.whatwg.org/html5#the-em-element I'm not sure this definition is wide enough to encompass the use that HTML 5 itself puts em to, using it for the This section is non-normative bits at the start of sections, such as: http://www.whatwg.org/html5#introduction That shouldn't be em. I've changed those to i in the spec. This meta-content use seems similar to an article by a guest author being prefaced by an italicized paragraph from a regular author introducing the guest. Or editoral comments inserted into somebody else's work, which are often in square brackets and italics as well as having - Ed at the end. Mainly it's just indicating some kind of separation from the main text. Yup. i is appropriate for those -- it's a different voice. On Fri, 19 Jun 2009, Nils Dagsson Moskopp wrote: I suggest that either the definition of em is broadened to include this sense, or these normativity designators are instead marked up with something like i class=normativity or i class=other. I suggest broadening the small element, mainly because it is already spec'd to contain some kind of meta-information (legal text). small is more for side comments than a different voice. Editorial comments can be marked up using the ins element, as I understand it. ins would be for the actual change, rather than a note about the change. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 11:14:21 +0200, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jul 12, 2009 at 11:20 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, 10 Jul 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? When would you fall back? For example, while parsing, would you fall back in between the video element being parsed and the first source element being parsed? You could display the fallback once you've reached the /video and not found an acceptable source. Technically it'd be when you pop the video element off the stack of open elements. I don't even think it'd be hard to pull down all sources and check that none of them are supported before displaying the fallback if types aren't specified on the source element. It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. While object has had a very poor implementation story, I don't think this was a big reason for that. Robert O'Callahan, Boris Zbarsky and other gecko layout folks can answer this better, but at least in gecko I don't think this part of object was particularly hard to implement correctly once we actually tried. Has any browser vendor argued against displaying the fallback due to high implementation burden? Implementation probably isn't the biggest burden here, specifying sane behavior is. For example: If fallback content is displayed after the last source element has failed, what should happen when a new source element is inserted? Switching back to video mode would make it even more special than object fallback and if you don't you'll just get stuck with fallback and have effectively broken the possibility of inserting source elements via scripts. Something like videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video is what you'd need to make the resource selection algorithm deal with fallback in a sane way when scripts are disabled, but this is too much of a corner case to justify the complexity in my opinion. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
2009/7/13 Ian Hickson i...@hixie.ch: On Fri, 10 Jul 2009, Jeff Walden wrote: And if a site wants to publish H.264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. We presumably don't want to make the use of uncumbered codecs easier. I agree. Moreover there are already two stable and widely used browsers that implement the current spec and websites are starting to use it. Since this fallback would be an incompatible change, please don't do it unless there's a *really* good reason for it. -- Lino Mastrodomenico
Re: [whatwg] Serializing HTML fragments (9.4)
On Thu, 09 Jul 2009 19:38:58 +0200, Boris Zbarsky bzbar...@mit.edu wrote: Kartikaya Gupta wrote: Opera and Chrome will alert c1somegt;stuff/c1morestuff (escaping the angle bracket inside the child element) and Firefox just outputs morestuff (presumably a bug). It's actually rather purposeful, at least in terms of the code. It'd be pretty easy to change to returning the textContent instead (so walking into kids). textContent wouldn't emit the tags. I think the spec currently matches what IE does. See https://bugzilla.mozilla.org/show_bug.cgi?id=125746 for the history here (the code has just been carried along since). I tried a couple of the other special elements (script and xmp) and they worked the same way. I think for compatibility the spec should say If the parent of the current node is a instead of If one of the ancestors of current node is a for the Text/CDATASection handling. No opinion on this, honestly. -- Simon Pieters Opera Software
Re: [whatwg] HTML 5 video tag questions
2009/7/13 Jeff Walden jwalden+wha...@mit.edu: On 12.7.09 23:20, Ian Hickson wrote: If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback forvideo-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support insidevideo), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. I'm fine doing this for myself: partly because it's pressure on Apple; perhaps mostly because I choose to make embedding videos that I can watch in-browser easy for myself, and because I don't particularly care if some portions of my audience are unable to see such videos and also choose not to download a browser that will display them (fallback content provides a download link -- I haven't made the effort to handle Safari4-sans-XiphQT yet, see supra). That said, my position will be uncommon, and I'm not particularly interested in making use of video right now harder for those who don't share it -- even if it comes at the expense of added pressure on Apple. In Wikimedia's case, we do care about the user experience, *but* will only be using Theora for the foreseeable future - H.264 is not an option. So browsers with Theora in video should Just Work, browsers without video will get the Java player or an in-browser plugin (and a note suggesting a browser that does Theora in video) and Safari is a nuisance because it's the exception and it *might* work but it *might* not and we have to reliably detect whether it does. (Presumably Apple would be happier with us suggesting XiphQT rather than suggesting Firefox!) iPhone Safari users (does iPhone Safari support video yet?) are, unfortunately, out in the cold until someone writes a Wikimedia client app that does Theora for them. That won't be us unless a volunteer steps up. Other phone users are likely out in the cold too (I don't know of any phones that support arbitrary Java applets in the browser). - d.
[whatwg] To post to this list, send your email to:
netarchit...@randasolutions.com M. A. Luttrell Sr. Sr. Web Applications Architect Randa Solutions Inc. 722 Rundle Ave. Nashville, Tennessee 37027 (615) 424-9988 This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited and could be subject to and be punishable by law. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. image001.jpg
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
On 7/13/2009 7:26 AM, Jonas Sicking wrote:
On Sun, Jul 12, 2009 at 9:00 PM, Ian Hicksoni...@hixie.ch wrote:
If we don't remove duplicates, then things like the .toggle() method could
have some quite weird effects.
Such as? The only one I can think of is that calling .toggle() would
remove multiple items. I don't see that as a problem?
I think Ian is referring to duplicates here as duplicates of the token
being removed, not as duplicates of any token in the underlying
attribute. In the current spec algorithm, removing or toggling a token
won't remove duplicates in other tokens.
Define .remove() as removing all tokens with the given value, and .toggle() as:
function toggle(token) {
if (this.contains(token))
this.remove(token);
else
this.add(token);
}
That's what toggle() does right now. (With the small difference that it
also returns a boolean to indicate if the token was removed or added).
I definitely think it'd be worth avoiding the code complexity and perf
hit of having the implementation remove duplicates if they appear in
the class attribute given how extremely rare duplicates are.
This is a bit unrelated, but when looking at the DOMTokenList
implementation, I had an idea about an alternative algorithm that could
be easier to implement and could also be described more simply in the
spec. The disadvantage is that the DOMTokenList methods mutating the
underlying string wouldn't preserve existing whitespace (which the
current algorithms try hard to do).
The idea is that any DOMTokenList method that mutates the underlying
string would do:
- split the attribute in unique tokens (preserving order).
- add or remove the token according to the method called.
- rebuild the attribute string by concatenating tokens together (with
a single space).
At first, this may look like inefficient (if implemented naively).
But I guess that implementations will usually keep both the attribute
string and a list of tokens in memory, so they wouldn't have to tokenize
the string on every mutation. There is a small performance hit during
attribute tokenization: the list of tokens would need to keep only
unique tokens. But after that, the DOMTokenList methods are very simple:
length/item() don't need to take care of duplicates, add/remove/toggle
are simple list manipulation (the attribute string could be lazily
generated from the token list when needed).
To summarize:
pros: simpler spec algorithms, simpler implementation
cons: less whitespace preservation, small perf hit during tokenization
I don't know if I'm missing something. Does this sound reasonable?
Sylvain
Re: [whatwg] Storage Events for a Specific Storage Area
We could make Storage into an EventTarget and also fire events on there, sure. As Jeremy said, this is something that might best be done in the next version; we're still trying to get the current features implemented in a stable and consistent fashion as it is. Sounds great. Although wouldn't now be the best time to introduce something new? Its not a breaking change (theoretically), its an additional feature. Its my understanding that most of Web Storage is undergoing changes (B-trees and SQL orthogonally), but the Storage interface is not going to change much? Is that because of current browser support? In general, though, I don't think it's critical, since you can easily work around it by checking which was changed based on the event data Fair enough. =) (I agree that your proposal would have made more sense. I'm sorry my learning experiences have such a detrimental effect on the Web! :-) ) We're all learning. =P -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.' - Joe
Re: [whatwg] Nested list
On Mon, Jul 13, 2009 at 4:01 AM, Simon Pieters sim...@opera.com wrote:
I think this is a bug in execCommand('indent') and should be fixed in
browsers.
The spec doesn't seem to list 'indent' at all. It would be helpful if it
was specified.
Yes, we need to specify how execCommand('indent' / 'insertorderedlist' /
'insertunorderedlist') works. But given that major UAs(Firefox, Internet
Explorer, WebKit) directly inserts ol / ul element without enclosing it
with li element, I think we should allow that construct in HTML5.
On Mon, Jul 13, 2009 at 4:07 AM, Adrian Sutton adrian.sut...@ephox.com
wrote:
It does introduce complexities when you try to indent list items more than
one level deeper than it's parent, but semantically that really doesn't
make
sense anyway. You can make it work by adding a new list item but with
list-style-type: none specified.
You still need to deal with margin / padding so you may specify them as
well. As you said, it's very hard to make UA-generated HTML correct. But
since major UAs produce the same DOM (ul / ol immediately inside another ul
/ ol), I don't see why we can't add that to HTML5 spec. After all, all we
need to do is to allow li / ul / ol elements inside ul / ol instead of just
li.
Does anyone see a serious compatibility issue with adding ol / ul as child
nodes of ol / ul? I feel like not allowing them is more problematic given
the situation.
Ryosuke
Re: [whatwg] Nested list
On Mon, Jul 13, 2009 at 10:22 AM, Ryosuke Niwarn...@google.com wrote: Does anyone see a serious compatibility issue with adding ol / ul as child nodes of ol / ul? I feel like not allowing them is more problematic given the situation. Part of the reason that browsers handle this-- ul li/li olli/li/ol li/li /ul -- pretty well is because, in HTML 4.01 (and earlier HTML specs), li was not required to be explicitly closed, so it would implicitly handle that ol as a child of the preceding li. (Inconsistencies in rendering most likely arise because the browser havs already found the explicit close to a list item before getting to the nested list.) Do you have use case for when a child list is *not* an item in the parent list? Otherwise, it doesn't make sense *not* to wrap the child list in the li element. Erik
Re: [whatwg] Nested list
On 13/07/2009 16:45, Erik Vorhes e...@textivism.com wrote: Part of the reason that browsers handle this-- ul li/li olli/li/ol li/li /ul -- pretty well is because, in HTML 4.01 (and earlier HTML specs), li was not required to be explicitly closed, so it would implicitly handle that ol as a child of the preceding li. (Inconsistencies in rendering most likely arise because the browser havs already found the explicit close to a list item before getting to the nested list.) Actually, at least Safari and FireFox treat the invalidly nested OL as a completely separate item - ie: they don't treat it as a child of the previous LI. You can see this quite clearly if you apply a style to the LI (or just look at the resulting DOM): ol li style=font-weight: bold; Item 1 olliNested/li/ol /li /ol ol li style=font-weight: bold;Item 1/li olliNested/li/ol /ol The first list is entirely bold, the second on Nested is not bold which matches the DOM structure that Safari shows. Do you have use case for when a child list is *not* an item in the parent list? Otherwise, it doesn't make sense *not* to wrap the child list in the li element. This is the real crux of why I think browser behavior is wrong - in every case I've seen, the author intends the indent to mean a sub-point, not a new point which for some reason is indented further. Given the rendering readers would expect an indented list item to be a sub-point as well. I don't see that HTML 5 has any choice but to define the current browser rendering and DOM structure as the way things are - changing the resulting DOM structure would break backwards compatibility. However, I'd really like to see browsers change to create correctly nested lists so the list structure actual matches the author intent. I'm somewhat doubtful browser vendors would want to change though and I must admit it does potentially create compatibility problems for existing JavaScript editors which would have to be explored more. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 628 200 182 x481 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] Nested list
On 13/07/2009 16:45, Erik Vorhes e...@textivism.com wrote: Part of the reason that browsers handle this-- ul li/li olli/li/ol li/li /ul -- pretty well is because, in HTML 4.01 (and earlier HTML specs), li was not required to be explicitly closed, so it would implicitly handle that ol as a child of the preceding li. (Inconsistencies in rendering most likely arise because the browser havs already found the explicit close to a list item before getting to the nested list.) Actually, at least Safari and FireFox treat the invalidly nested OL as a completely separate item - ie: they don't treat it as a child of the previous LI. You can see this quite clearly if you apply a style to the LI (or just look at the resulting DOM): ol li style=font-weight: bold; Item 1 olliNested/li/ol /li /ol ol li style=font-weight: bold;Item 1/li olliNested/li/ol /ol The first list is entirely bold, the second on Nested is not bold which matches the DOM structure that Safari shows. Do you have use case for when a child list is *not* an item in the parent list? Otherwise, it doesn't make sense *not* to wrap the child list in the li element. This is the real crux of why I think browser behavior is wrong - in every case I've seen, the author intends the indent to mean a sub-point, not a new point which for some reason is indented further. Given the rendering readers would expect an indented list item to be a sub-point as well. I don't see that HTML 5 has any choice but to define the current browser rendering and DOM structure as the way things are - changing the resulting DOM structure would break backwards compatibility. However, I'd really like to see browsers change to create correctly nested lists so the list structure actual matches the author intent. I'm somewhat doubtful browser vendors would want to change though and I must admit it does potentially create compatibility problems for existing JavaScript editors which would have to be explored more. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 628 200 182 x481 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
[whatwg] hash sum tags of binary files and code blocks?
What if one included hash sums of every binary file in html tags, plus embedded hash sums in streaming file blocks, then the client would never need to look at time stamps/expire headers to determine if it could cache the objects. That would make caching very easy on mobile devices with slow datalinks, make it possible for service providers to cache objects globally for their customer base. One could also augment whole code blocks with hash sums for example css this could possibly be more efficient than time expire. img src=example.jpg md5=f2bd08fae5adb96c9befa02bddb4a90c hash md5=bda497e29a81a038208ab94101e2e793 skipaheadlines=10 style /style /hash link rel=stylesheet type=text/css href=external-style-sheet-file.css md5=dee0b8572297fe4e3b004cfe188ecad3/ no need to load that style sheet ever again if it's contents has not changed. //Christian Nygaard
Re: [whatwg] hash sum tags of binary files and code blocks?
2009/7/13 Christian Nygaard christiannyga...@gmail.com: What if one included hash sums of every binary file in html tags, plus embedded hash sums in streaming file blocks, then the client would never need to look at time stamps/expire headers to determine if it could cache the objects. That would make caching very easy on mobile devices with slow datalinks, make it possible for service providers to cache objects globally for their customer base. One could also augment whole code blocks with hash sums for example css this could possibly be more efficient than time expire. img src=example.jpg md5=f2bd08fae5adb96c9befa02bddb4a90c How would this interact with HTTP Accept header? It seems each resource would be required to have only a single presentation, and that the HTML was intimately aware of the details of that presentation, or alternatively intimately aware of what presentation the user agent would request. hash md5=bda497e29a81a038208ab94101e2e793 skipaheadlines=10 style /style /hash link rel=stylesheet type=text/css href=external-style-sheet-file.css md5=dee0b8572297fe4e3b004cfe188ecad3/ no need to load that style sheet ever again if it's contents has not changed. This scheme doesn't really fit HTTP at all. However that's not to say it's interesting. In fact swathes of research have been devoted to designing access layers like this (they're often called content addressable networks). Introducing little bits of it into HTML seems like the wrong layer to be working on. David -- Reality is that which, when you stop believing in it, doesn't go away. — Philip K. Dick
Re: [whatwg] hash sum tags of binary files and code blocks?
Hi Christian, have you ever considered just making the md5 (or maybe just a shorter CRC) part of the filename of the file you want to cache? Then you can send Expiry headers for 6 months or a years time for those files and you'll get the same behaviour. Aron
Re: [whatwg] hash sum tags of binary files and code blocks?
On Mon, Jul 13, 2009 at 11:41 AM, Aron Spohra...@aspohr.de wrote: Hi Christian, have you ever considered just making the md5 (or maybe just a shorter CRC) part of the filename of the file you want to cache? Then you can send Expiry headers for 6 months or a years time for those files and you'll get the same behaviour. FWIW, I do this. I set far-future expiry headers on my CSS and images. If I need to make a change after it's gone live, I append a query parameter with a current timestamp. There isn't anything on the other end which responds to the query param, but it does indicate that it's a new resource to the browser's caching algorithm, which is precisely what I want. The new version will then stay cached until I change the query param again. Using a hash or version number instead of a timestamp is equivalent. (I could, of course, actually hook up a script on the server-side which remembers the previous versions of the resource and will serve them up as requested, but that hasn't ever been necessary so far.) ~TJ
Re: [whatwg] Serving up Theora video in the real world
On Mon, Jul 13, 2009 at 1:43 AM, Philip Jägenstedt phil...@opera.comwrote: Also, I've reported bugs on Safari and Chrome (I think, neither give confirmation that the report has been sent successfully!) That's odd. Both bugs.webkit.org and crbug.com tell me when I've filed a bug, and give me the bug number for reference. How did you file your issues? (Feel free to respond privately if you want, in order to avoid spamming the list) PK
[whatwg] HTML5+RDFa first Editors Draft published
The first public Editors Draft of RDFa for HTML5 was published earlier today. You can view the draft in two forms: * [1] HTML5+RDFa Section (small 34K HTML document) * [2] Complete HTML5+RDFa Specification (very large 4MB HTML document) This blog post explains how this draft came to be, how it was published via the World Wide Web Consortium, and what it means for the future of RDFa and HTML5: http://blog.digitalbazaar.com/2009/07/13/html5rdfa/ -- manu [1]http://dev.w3.org/html5/rdfa/rdfa-module.html [2]http://dev.w3.org/html5/rdfa/Overview.html#rdfa -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
Re: [whatwg] Serializing HTML fragments (9.4)
Simon Pieters wrote: It's actually rather purposeful, at least in terms of the code. It'd be pretty easy to change to returning the textContent instead (so walking into kids). textContent wouldn't emit the tags. Yes, true. I thought that's what you were asking for... I think the spec currently matches what IE does. Does IE even support adding a child element to a script? One problem with what the spec currently says, if I read it correctly, is that it doesn't round-trip scripts correctly, at least as far as I can see. What Gecko serializes as the innerHTML of the script is something that, if you set the script's innerHTML to that value, will give a script that is equivalent to the original one if it's executed. That doesn't seem to be the case for the spec's current behavior... -Boris
Re: [whatwg] HTML 5 video tag questions
Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. ~TJ
Re: [whatwg] Browser Bundled Javascript Repository
On Mon, Jul 13, 2009 at 12:49 AM, Jonas Sickingjo...@sicking.cc wrote: 2. How do we deal with identifying libraries. As Aaron Boodman pointed out, SHA hashes means that you can't make upgrades for security problems etc. I think a hash would be fine. You don't want to load a different version of the library than the author intended, even if it may supposedly have bug fixes. Perhaps the author is relying on the bugs that were fixed. This should be transparent, so that the same script will always be used whether browsers support this feature or not. 3. Compat when the browser doesn't have a library cached. A solution that includes using a different uri for browsers that do support caching than browsers that don't is scary since there is a big risk that the author will forget to update one but not the other. How about you have an extra HTTP header like X-Content-Hash? This could provide a SHA256 hash (or something else that looks safe for now, progressively upgradeable) of the content. The browser can keep its cached copies of these files indexed by hash. If it tries downloading a file, and notices that the hash is the same as a file already downloaded, it can terminate the HTTP connection and use the existing file (even if it's from a different site). It will then proceed as though it had actually downloaded the file: e.g., it will respect the Expires headers separately (two sites might serve the same file but have different expectations about how likely it is to change). Of course, when the file is downloaded, it would be indexed based on actual SHA256, not the reported SHA256. This way you can't poison the cache. If an incorrect hash is provided, that will potentially result in the wrong script being used, of course, but you can't generate a preimage of the bad hash (hopefully!), so attackers can't exploit it. Unless they can inject HTTP headers, but then you're screwed anyway. So this would basically be like ETag, but with the tag unique across all sites. In fact, maybe piggybacking it on ETag would be a better idea, so you don't have to do stuff like terminate the TCP connection unexpectedly. (Which I don't *think* would be harmful? but is certainly suboptimal.) Just define a magic ETag format that nobody's currently using. I'm not sure how useful this would actually be, though. Are there really *so* many sites using the *exact* same version of jQuery or any other single library? It seems like a better idea would be to get all the valuable user-created APIs standardized and implemented in some form cross-browser, as a few (e.g., getElementsByClassName) have been. Then the common uses of jQuery or whatever would just be compatibility layers for legacy browsers. Kind of like how a bunch of Boost is getting added to standard C++. Of course, this requires more effort, but it's more likely to actually work, in the long term. I believe all these problems are solvable, but they do need to be solved before considering inclusion in any spec. I'm also not convinced this needs to be included in the HTML5 spec, but that might depend on what the ultimate solution looks like. The most obvious place to solve this seems to be HTTP, not HTML. HTTP is closer to the resource itself. If you do something with HTML, like an extra link attribute, then you're going to get authors updating the HTML but not the thing it points to or vice versa. An ETag-like solution would be implemented either in the web server or whatever script is serving the content, and those should always know whether the file has changed. (Modulo pathological behavior like something changing the file and then forging the mtime/ctime.) So yeah, doesn't seem like something for HTML 5.
Re: [whatwg] Nested list
On Mon, Jul 13, 2009 at 11:34 AM, Ryosuke Niwarn...@google.com wrote: We can define it in this way. When a list A appears within anther list B (without being enclosed by li), then the list A is a sublist of B and that lists A and B constitutes a tree structure. When a list C appears within a list item of the list B, then list C is a list appears in a paragraph of a list item of B. i.e. C ad B does not constitute a tree structure. This can be seen from the way those two constructs are rendered in major UAs. Namely, when lists A and B are nested, you don't see a bullet before A. Because A and B together constitutes a tree-structure, this rendering is semantically correct. On the other hand, UAs render a bullet before C. B has a list item that happens to contain a list, but that doesn't prevent B from having a bullet for that particular list item. While I think I understand your description, I'm a little concerned for a few reasons. 1. Depending on context, lists within lists don't render differently than lists within list items do. 2. How does the User Agent determine if a list within a list is part of the preceding li if that li isn't closed? Is it part of the li or something on its own? 3. Why should ol and ul provide different semantic meaning depending on context? Won't that lead to confusion? 4. If two lists aren't actually supposed to be items in the same list, why would you group them as a list? Shouldn't they be separate entities entirely? I've cobbled together a demonstration page to address some of these issues (more clearly, I hope): http://textivism.com/list-items/ Erik Vorhes
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. That would require the parser to inspect an attribute to determine if the element is a void element (one that does not have a closing tag) or not, which I've been told is not very nice. Are there any other such cases? This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Browser Bundled Javascript Repository
On Mon, Jul 13, 2009 at 2:01 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: I'm not sure how useful this would actually be, though. Are there really *so* many sites using the *exact* same version of jQuery or any other single library? Yes there are. jQuery doesn't put out very many updates, and I don't think most people alter their jQuery file. Remember that this would also help with, frex, plugins for jQuery. Some of them (especially the jQuery UI plugins) are really fat, and being able to cache them across many sites could be useful. It seems like a better idea would be to get all the valuable user-created APIs standardized and implemented in some form cross-browser, as a few (e.g., getElementsByClassName) have been. Then the common uses of jQuery or whatever would just be compatibility layers for legacy browsers. Kind of like how a bunch of Boost is getting added to standard C++. Of course, this requires more effort, but it's more likely to actually work, in the long term. That'd only address the things that the various vendors can agree are 'standard' enough to push into a common API. It would also mean that legacy browsers break completely, as you're depending on the browser's built-in libraries that don't exist in older versions. It's much better to lean on existing files so that older browsers download them like normal, and newer browsers download them once and then cache them across the web. I believe all these problems are solvable, but they do need to be solved before considering inclusion in any spec. I'm also not convinced this needs to be included in the HTML5 spec, but that might depend on what the ultimate solution looks like. The most obvious place to solve this seems to be HTTP, not HTML. HTTP is closer to the resource itself. If you do something with HTML, like an extra link attribute, then you're going to get authors updating the HTML but not the thing it points to or vice versa. An ETag-like solution would be implemented either in the web server or whatever script is serving the content, and those should always know whether the file has changed. (Modulo pathological behavior like something changing the file and then forging the mtime/ctime.) So yeah, doesn't seem like something for HTML 5. Agreed, and your approach seems workable to me. ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedtphil...@opera.com wrote: On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. That would require the parser to inspect an attribute to determine if the element is a void element (one that does not have a closing tag) or not, which I've been told is not very nice. Are there any other such cases? Hm? I'm not sure what you mean here. It would work like this: video source src=foo source src=bar source fallback pI'm some fallback content!/p /video You'll see the p if the browser doesn't support video, or if the resource selection algorithm hits that third source and hasn't found anything it can play yet. It wouldn't change whether the source is a void element or not. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. ~TJ
Re: [whatwg] Browser Bundled Javascript Repository
On Mon, Jul 13, 2009 at 3:21 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: Yes there are. jQuery doesn't put out very many updates, and I don't think most people alter their jQuery file. It's only one file, not multiple? And people don't inadvertently change newline style, or minify it using different incompatible minifiers, or combine it with their other files so that they only serve a single JS file? And you're taking into account that certainly the majority of sites don't use jQuery at all? And that you'd have to remove it when the user cleared their cache? Does anyone have statistics on how useful this would be in real life? I suspect only marginally. That'd only address the things that the various vendors can agree are 'standard' enough to push into a common API. That would be enough for most people. It would also mean that legacy browsers break completely, as you're depending on the browser's built-in libraries that don't exist in older versions. No, because you could have compatibility libraries that you just wouldn't load if the browser already supported the features.
Re: [whatwg] Browser Bundled Javascript Repository
On Mon, Jul 13, 2009 at 3:20 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Mon, Jul 13, 2009 at 3:21 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: Yes there are. jQuery doesn't put out very many updates, and I don't think most people alter their jQuery file. It's only one file, not multiple? Yes. And people don't inadvertently change newline style, or minify it using different incompatible minifiers, As jQuery serves a minified version directly, probably not. I suspect that most of us just download the file and pop it straight onto the server. or combine it with their other files so that they only serve a single JS file? This is a possibility, but I don't know how often this happens in practice. And you're taking into account that certainly the majority of sites don't use jQuery at all? Was that ever in question? The point is that jQuery (and other libraries) are used *often enough* that caching across websites can be useful. This is the whole reason that the Google-hosted version is useful. Automatic caching from the browser just allows smaller-use libraries (and plugins for those libraries) to benefit without having to convince a central authority to host them and donate bandwidth. And that you'd have to remove it when the user cleared their cache? I'm not certain what this has to do with the proposal. Does anyone have statistics on how useful this would be in real life? I suspect only marginally. For starters, anyone know the usage statistics on the Google-hosted versions? That'd only address the things that the various vendors can agree are 'standard' enough to push into a common API. That would be enough for most people. The issue is getting everyone to agree on enough. I use quite a lot of jQuery's tools, for example. Even if a lot of it was pushed into the browsers, I'd still probably have to use jQuery for some of the functionality that wasn't included. Of course, at that point jQuery could potentially be much smaller. And what if the API ended up resembling Prototype? I *greatly* prefer jQuery over all the other frameworks, and would have a much more difficult time using anything else. It would also mean that legacy browsers break completely, as you're depending on the browser's built-in libraries that don't exist in older versions. No, because you could have compatibility libraries that you just wouldn't load if the browser already supported the features. Yes, so now I have to feature-test those things before trying to use them. Dealing with legacy javascript support is annoying enough right now - I'd prefer that these things gradually migrate into the core and the library I use still just wrap around it. The fact that standardized javascript features tend to end up being clunky due to their requirement of language independence makes me not really want this either. I much prefer a library that presents a good, clean language to me, and handles the clunky aspects in the background. I doubt we'll ever have a standardized AJAX function as clean and easy to use to use as $.get(), frex. ~TJ
Re: [whatwg] Browser Bundled Javascript Repository
I honestly can't see the benefit of bundling common libraries at all. It requires a bunch of infrastructure to manage it and quickly becomes out of date. Not worth it to save a few tens of K as a one-time download - not a significant amount at all in today's terms. What would help is if more people could link a script from a common location so that it was already cached by the standard browser mechanisms. This is already happening to some extent. But linking external scripts does have a problem in that you have to trust the site you're linking not to change the script (or get compromised) to add malicious features. A cryptographic hash of the file you expect could be used to mitigate this issue, perhaps for other types of file too. And such a feature could fall within HTML5's purview. For example: script type=text/javascript src=http://www.sharedscripts.com/jquery-1.2.3.js; contenthash=sha1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d link rel=stylesheet type=text/css src=http://www.sharedscripts.com/nice-4.5.6.css; contenthash=sha1:0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 21:28:45 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedtphil...@opera.com wrote: On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. That would require the parser to inspect an attribute to determine if the element is a void element (one that does not have a closing tag) or not, which I've been told is not very nice. Are there any other such cases? Hm? I'm not sure what you mean here. It would work like this: video source src=foo source src=bar source fallback pI'm some fallback content!/p /video You'll see the p if the browser doesn't support video, or if the resource selection algorithm hits that third source and hasn't found anything it can play yet. It wouldn't change whether the source is a void element or not. I thought you meant video source fallback fallback content here /source /video I would prefer if fallback content and source elements weren't mixed on the same level, but maybe that's just me. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) Once the source element is iterated by the resource selection algorithm and starts loading, the fallback attribute or the whole source element might be removed. You would have to set a flag at some point to remember the fallback state and unset it... when? What is the effect of video source fallback source src=cant.play.ogg fallback here /video ? Is fallback irrevocable or could the same video element go back to showing video under some circumstances? Does audio also have fallback content? This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. Yes, handling the (minor) use case video support + no supported source + no script would be nice, but only if it doesn't make an even bigger mess of the resource selection algorithm and doesn't allow switching back and forth between video and fallback. The browsers that have already shipped with video don't support fallback but they are the ones that are the most likely to need it (assuming that format support will get better over time). It would be nice to hear what they think about all of this. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 17:01:26 -0400, Philip Jägenstedt phil...@opera.com
wrote:
Does audio also have fallback content?
With audio, you can set its display to 'none' and the audio will still
play. However, if its display is set to 'none' and the element were to
fall back to a child object element that loads a plug-in, things wouldn't
work because plug-ins don't work with a display of 'none'.
You would then have to detect that audio fell back so you could set its
display to inline-block for example so the fallback plug-in would
actually load. Or, there'd have to be a new css selector to handle this
like audio::fallback_state { display: inline-block} or a parent selector
on the child object element that was only applied when audio fell back
to it. Or, the browser would have to make plug-in objects that are
descendants of an audio element work with a display of 'none'.
The same applies to video if you want to set its display to 'none' and
just hear the audio.
--
Michael
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedtphil...@opera.com wrote: The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. While object has had a very poor implementation story, I don't think this was a big reason for that. Robert O'Callahan, Boris Zbarsky and other gecko layout folks can answer this better, but at least in gecko I don't think this part of object was particularly hard to implement correctly once we actually tried. Has any browser vendor argued against displaying the fallback due to high implementation burden? Implementation probably isn't the biggest burden here, specifying sane behavior is. For example: If fallback content is displayed after the last source element has failed, what should happen when a new source element is inserted? Switching back to video mode would make it even more special than object fallback and if you don't you'll just get stuck with fallback and have effectively broken the possibility of inserting source elements via scripts. Something like videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video is what you'd need to make the resource selection algorithm deal with fallback in a sane way when scripts are disabled, but this is too much of a corner case to justify the complexity in my opinion. I think fallback contents is simply defined as the contents of the video, minus any source elements (which wouldn't render anyway). No need for new-fallback-element. The simplest solution would be to display the fallback when there aren't any source (or @src) elements being either displayed or waiting to load. I think spec-wise the simplest thing would be to display fallback when The networkState of the element is NETWORK_NO_SOURCE. This way even incremental rendering of the fallback contents would work fine. The only case that's weird is markup like: video lots and lots of fallback here source src=... /video There is a risk that content would be displayed, and then switch to displaying video. This doesn't seem like a big problem as it seems more likely that people will put the source first. And if someone doesn't the effects aren't very bad. Alternatively we could use the following rules: 1. The networkState of the element is NETWORK_NO_SOURCE. *and* 2. The video element is fully parsed. I.e. it has been removed from the stack of open elements. This would mean that incremental rendering doesn't work. This doesn't seem any worse than what we have now when fallback is never displayed. Though I think it'd work fine always display fallback whenever the networkState is NETWORK_NO_SOURCE. / Jonas
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedtphil...@opera.com wrote: I thought you meant video source fallback fallback content here /source /video I would prefer if fallback content and source elements weren't mixed on the same level, but maybe that's just me. Eh, fallback content for non-video browsers is already there, so it's nothing new. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) Once the source element is iterated by the resource selection algorithm and starts loading, the fallback attribute or the whole source element might be removed. You would have to set a flag at some point to remember the fallback state and unset it... when? What is the effect of video source fallback source src=cant.play.ogg fallback here /video ? It would hit the first source, note that there's no @src, see that there is @fallback, and immediately drop to showing fallback content. Is fallback irrevocable or could the same video element go back to showing video under some circumstances? It should be revocable in the exact same circumstances that a video element might start playing from one source, and then switch to another. From my reading of the algorithm I don't think this is possible, so fallback would be irrevocable. Does audio also have fallback content? It uses source and the same source-selection algorithm (and the same fallback situation in the case of non-audio browsers), so yes. This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. Yes, handling the (minor) use case video support + no supported source + no script would be nice, but only if it doesn't make an even bigger mess of the resource selection algorithm and doesn't allow switching back and forth between video and fallback. From what I can tell of the resource selection algorithm, fallback should be irrevocable, just like a successful source load is. The resource selection algorithm appears to need fairly trivial changes to accommodate this. Step 4, when parsing @src from video, insert a new substep between substeps 2 and 3. Pull the first sentence from the current substep 3 into this new substep, and say something like If the element has a fallback attribute, abort this algorithm immediately and display the fallback content. When parsing source elements, change step 3 so that whenever any of those conditions are met, if the source has @fallback the algorithm aborts immediately and shows the fallback content, otherwise it fires the error event and jumps to the search loop step as normal. Alternately, we could just put @fallback always on the video element directly, rather than on source. That would preserve the first part of what I said, but now we have a step between substeps 9 and 10 that checks for @fallback on the video. If it finds it, it immediately aborts and shows the fallback content, otherwise substep 10 proceeds normally (waiting forever). ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 4:28 PM, Jonas Sickingjo...@sicking.cc wrote: This way even incremental rendering of the fallback contents would work fine. The only case that's weird is markup like: video lots and lots of fallback here source src=... /video There is a risk that content would be displayed, and then switch to displaying video. This doesn't seem like a big problem as it seems more likely that people will put the source first. And if someone doesn't the effects aren't very bad. That's against spec anyway (source elements, if present, should be the first children of video, and are then followed by fallback content if present), so it's not a big deal if it displays badly.
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
On Mon, Jul 13, 2009 at 6:24 AM, news.gmane.orgsylvain.pas...@gmail.com wrote:
On 7/13/2009 7:26 AM, Jonas Sicking wrote:
On Sun, Jul 12, 2009 at 9:00 PM, Ian Hicksoni...@hixie.ch wrote:
If we don't remove duplicates, then things like the .toggle() method
could
have some quite weird effects.
Such as? The only one I can think of is that calling .toggle() would
remove multiple items. I don't see that as a problem?
I think Ian is referring to duplicates here as duplicates of the token
being removed, not as duplicates of any token in the underlying
attribute. In the current spec algorithm, removing or toggling a token
won't remove duplicates in other tokens.
That's what I was referring to too. For example if a DOMTokenList were
to contain two hello tokens, and the user called .toggle(), that
would remove two tokens from the list (both with the value hello).
Define .remove() as removing all tokens with the given value, and
.toggle() as:
function toggle(token) {
if (this.contains(token))
this.remove(token);
else
this.add(token);
}
That's what toggle() does right now. (With the small difference that it also
returns a boolean to indicate if the token was removed or added).
Yup, so I don't really see a problem with allowing multiple tokens of
the same value.
This is a bit unrelated, but when looking at the DOMTokenList
implementation, I had an idea about an alternative algorithm that could be
easier to implement and could also be described more simply in the spec. The
disadvantage is that the DOMTokenList methods mutating the underlying string
wouldn't preserve existing whitespace (which the current algorithms try hard
to do).
The idea is that any DOMTokenList method that mutates the underlying string
would do:
- split the attribute in unique tokens (preserving order).
- add or remove the token according to the method called.
- rebuild the attribute string by concatenating tokens together (with a
single space).
At first, this may look like inefficient (if implemented naively).
But I guess that implementations will usually keep both the attribute string
and a list of tokens in memory, so they wouldn't have to tokenize the string
on every mutation. There is a small performance hit during attribute
tokenization: the list of tokens would need to keep only unique tokens. But
after that, the DOMTokenList methods are very simple: length/item() don't
need to take care of duplicates, add/remove/toggle are simple list
manipulation (the attribute string could be lazily generated from the token
list when needed).
To summarize:
pros: simpler spec algorithms, simpler implementation
cons: less whitespace preservation, small perf hit during tokenization
I don't know if I'm missing something. Does this sound reasonable?
I do agree that the spec seems to go extraordinary far to not touch
whitespace. Normalizing whitespace when parsing is a bad idea, but
once the user modifies the DOMTokenList, I don't see a lot of value in
maintaining whitespace exactly as it was.
Ian: What is the reason for the fairly complicated code to deal with
removals? At least in Gecko it would be much simpler to just
regenerate the string completely. That way generating the string-value
could just be dropped on modifications, and regenerated lazily when
requested.
/ Jonas
Re: [whatwg] b Lede Example
On Thu, 18 Jun 2009, Smylers wrote: One of the examples of b is marking up a lede paragraph: http://www.whatwg.org/html5#the-b-element Is a lede semantically relevant to the document such that it needs to be in the mark-up? Sure, why not? Emboldening the first paragraph of an article seems like a matter of style to me, similar to using a drop cap for the first letter. It's not always just the first paragraph. Sometimes it's the first sentence, or the first two paragraphs, or the first phrase, it varies based on the conventions of the publication and on the content. For example, if an article were syndicated to multiple news sites it's conceivable that some would style the lede differently from other paragraphs and some wouldn't -- and doing so or not wouldn't affect the meaning of the article or its interpretation by readers. Indeed, some would remove the styling of the b, some would not. It shows that b is not presentational in this case. So using CSS (I think article h2 + p would do it) would seem more appropriate than any mark-up here. Especially since b is labelled as a last resort. I don't see how the CSS can always know what the lede is. Highlighting specifically just the first sentence (even if the first paragraph has multiple sentences) is more awkward, in that I don't think it's currently possible with CSS. But that it exists as a plausible choice for presenting an article demonstrates how much a matter of styling, rather than content, this area is. And a limit of CSS should be fixed in CSS, not HTML. (span class=lede can always be used as a work-around.) I think it would be wrong to depend on CSS here, because even though the lede's desired presentation might vary from publication to publication, if the author wants a lede, then it should render, whether or not the user supports CSS. In any case, this is just an example. Do you have any suggestions of another example to replace it? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Tool Implementor Audience
On Thu, 18 Jun 2009, Smylers wrote: One of the audiences for HTML is stated as implementors of tools that are intended to conform to this specification: http://www.whatwg.org/html5#audience That seems circular, verging on tautologous: a tool author wondering whether this spec is relevant to her (and therefore whether her tool should aim to conform with it) isn't any better informed having read the above. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Dom as Audience Prereq
On Thu, 18 Jun 2009, Smylers wrote: The audience section states familiarity with Dom Core and Dom Events as prereqs for reading the HTML 5 spec: http://www.whatwg.org/html5#audience As somebody without this Dom background there are certainly many parts of the spec which I've found both understandable and useful (to a web author). There may be parts which do require Dom knowledge, but as written it sounds like a prereq for understanding any part of the spec, and as such may unnecessarily put people off. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 and HTML4
On Thu, 18 Jun 2009, Smylers wrote: The 'History' section starts: Work on HTML 5 originally started in late 2003, as a proof of concept to show that it was possible to extend HTML4's forms ... -- http://www.whatwg.org/html5#history-0 Having HTML 5 (with a space) and HTML4 (no space) seems oddly inconsistent. Could we have them matching? If this is the biggest problem you can find, we're doing well. :-) Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Adding canonical to the list of allowed link types
Currently rel=canonical ( http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html) is not in the allowed set of link types listed at http://www.whatwg.org/specs/web-apps/current-work/#linkTypes . Looking back through archived posts, it seems that it was once briefly mentioned in passing but there was no discussion regarding its addition to the spec. Considering its usefulness, are there plans to add canonical to the official list of accepted values? Regards, James
Re: [whatwg] Plus Signs in Signed Integers
On Thu, 18 Jun 2009, Smylers wrote: The algorithm for parsing signed integers does not allow an optional plus sign before positive integers; that is, parsing +4 will return an error at step 8 of this algorithm: http://www.whatwg.org/html5#rules-for-parsing-integers That is inconsistent with the algorithm for non-negative integers, which tolerates (and ignores) a leading plus sign (step 6): http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers I've made + be tolerated by the signed parser also. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Charset override table should match case of IANA registry
On Thu, 18 Jun 2009, Geoffrey Sneddon wrote: Although charsets are case insensitive, it'd probably be best to be consistent with the IANA registry. The only change this means makes is changing Windows-* to windows-*. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] External document subset support
On Fri, 19 Jun 2009, Brett Zamir wrote: 1) Firefox and Webkit, should not give a single point of failure for a missing entity as they do now, (unless they switch to a validating parser which finds no declaration in the external file and the user is in validation mode), since such failures in a document with an external DTD are NOT well-formedness errors unless the document deliberately declares standalone=yes. 2) Explorer, which no longer seems to require in IE8 that the document be completely described by the DTD as I believe it had earlier (though it will report errors if the document violates rules which are specified), should, per the spec, really only report validation errors upon user option (ideally, I would say, off by default, and activatable on a case-by-case as well as preference-based basis). This will possibly speed things up if the option could be disabled as well as let their browser work with documents which violate validation. But this issue is not as serious as #1, since #1 prevents even valid documents from being interoperably viewed on the web. [...] These issues seem out of scope for HTML5. I recommend bringing them up with the respective vendors directly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Week Strings
On Fri, 19 Jun 2009, Smylers wrote: For input type=week elements the spec requires: The value attribute, if specified, must have a value that is a valid week string. -- http://www.whatwg.org/html5#week-state But the spec's HTML source contains this comment immediately afterwards: !-- ok to set out-of-range value, we never know when we might have to represent bogus input -- Does that comment mean that the above requirement will be changed to something along the lines of must have a value that is a syntactically valid week string but may represent a week that doesn't actually exist? No, it just means that there's no requirement that the value= be within the range given by min= and max=. It's a reminder to myself in case I notice there's no such requirement one day and go and add one thinking it was a mistake. That is, the author can seed a browser's week-picker control to a value which the browser must not submit back to the server? So long as it is a valid week string, yes. In general determining that something is a valid week string requires knowing which day of the week the year in question begins on. For example 2009-W53 is a valid week string (because 2009 began on a Thursday) but 2010-W53 isn't (because 2010 will begin on a Friday). Browsers will need to do this to know whether they can submit a week value. Yup. The spec doesn't appear to provide an algorithm for determining which day of the week a year begins on (however I am not a browser developer; possibly this is sufficiently straightforward that those who are don't need it spelling out). As far as I can tell, it is well-defined in the spec. Currently Validator.nu accepts this: input type=week value=2010-W53 but not this: input type=week value=2010-W54 If out-of-range week values are to be permitted in input elements then a validator should permit both of them. Conversely if they aren't permitted then it should accept neither of them (and therefore have to implement a 'which day is January 1st' algorithm, which I'm guessing it currently doesn't). Please report such bugs straight to Henri. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Week Strings
On Fri, 19 Jun 2009, 'Smylers' wrote: And even states the blindingly obvious: The 'week number of the last day' of a week-year with 53 weeks is 53; the 'week number of the last day' of a week-year with 52 weeks is 52. I use the term week number of the last day as a kind of function in the spec, so while it may be obvious, it has to be listed explicitly otherwise one could argue that it isn't defined. (I could probably just stop using it as a function and just assume that people will apply common sense, but sometimes that doesn't work so well...) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Date or Time String with Just a Time
On Fri, 19 Jun 2009, Smylers wrote: A valid time string, such as 10:55, is one of the possible values for a valid date or time string: http://www.whatwg.org/html5#vaguer-moments-in-time But step 10 of the parsing rules says: If the 'time present' flag is true, but 'position' is beyond the end of 'input', then fail. That would appear to fail on 10:55. I think making step 10 begin If the 'date present' and 'time present' flags are both true (as step 11 already does) fixes this. Um, yes. Good call. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hasFeature() When Only 1 Syntax is Supported
On Sat, 20 Jun 2009, Smylers wrote: The current text suggests that a user-agent may choose to support only the HTML syntax (not XHTML) but should still return true for hasFeature(XHTML, 5.0). If that isn't intended then the requirements for hasFeature() should be changed to depend on the syntaxes chosen to be implemented. If it _is_ intended (and given various things browsers have to do for web compatibility, it wouldn't surprise me) then perhaps it would be better to spell this out explicitly, since it's counter-intuitive. hasFeature() currently has the implementation requirements: User agents should respond with a true value when the hasFeature method is queried with these values. -- http://www.whatwg.org/html5#dom-feature-strings: Where these values are (HTML, 5.0) and (XHTML, 5.0). However while supporting both HTML and XHTML is encouraged, user-agents may choose to support only one of them: http://www.whatwg.org/html5#conformance-requirements On Mon, 22 Jun 2009, Simon Pieters wrote: Maybe the spec should remove these feature strings altogether and encourage authors to use more accurate methods of detecting support. On Wed, 24 Jun 2009, Simon Pieters wrote: The spec is now gaining all the remaining stuff from DOM2 HTML, so this note is incorrect: Note: The interfaces defined in this specification are not always supersets of the interfaces defined in DOM2 HTML; some features that were formerly deprecated, poorly supported, rarely used or considered unnecessary have been removed. Therefore it is not guaranteed that an implementation that supports HTML 5.0 also supports HTML 2.0. I'm thinking that the spec should maybe just use 2.0 instead of 5.0, since it's what browsers do and there might be pages that check for this. Meanwhile it seems useful to return false as appropriate if the UA only allows one of the syntaxes, as Smylers points out. I've removed everything but HTML/2.0. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
