[whatwg] Issues concerning the base element and xml:base
This, along with the checkin I just made, should resolve all the e-mails that have been sent regarding base. Please let me know if I missed anything or if you see any new issues. On Sun, 11 Feb 2007, Geoffrey Sneddon wrote: To take this from a discussion last month on atom-syntax: What is meant to happen if you set innerHTML of a div where the set value has both a base and an a? Nothing much. The base element will appear in the DOM (as a child of the div), but it will not have any effect. On Sun, 11 Feb 2007, Geoffrey Sneddon wrote: The point is whether it: a) Gets inserted into the head, and changes all the links in the document. b) Appears in some magic place, and changes the links in the HTML fragment. c) Gets ignored. None of the above. It appears in the DOM but has no effect. On Sun, 11 Feb 2007, Geoffrey Sneddon wrote: Safari 2.0.4/419.3: (1) Inserted in DOM (in the innerHTML location). Firefox 2.0.0.1: (3) Inserted in DOM (in the innerHTML location). IE/Mac 5.2.3: (2) (anyway to view the DOM tree?) Opera 9.10: (1) DOM Snapshot for some reason isn't working. IE6/Win: (2) The new base never appears in DOM, but the full absolute URLs are in the DOM. IE7/Win: (3) The new base never appears in DOM, but the full absolute URLs are in the DOM. In conclusion, Safari and Opera change all the links, IE5/Mac and IE6/Win both change links within the fragment, and Firefox and IE7/Win don't change any links. The latter is the option I'm following for now. Note that browsers all do _different_ things for target= than for href=. The spec has made them act the same for now. I'm not sure this is workable, we'll have to see when the browser vendors try to get this interoperable. I can't imagine that it's a huge issue given that the browsers are so far from each other in terms of what they do here. I'm going to do a study of some subset of the Web to see how common this is (at least the static case; I can't really do much about the scripted case). On Fri, 2 Mar 2007, Anne van Kesteren wrote: I think base should also be allowed in XML documents. It simplifies the language, it already needs to be supported and base is able to set Document.baseURI where xml:base can at most set Document.documentElement.baseURI. (Document.baseURI influences how XMLHttpRequest works for instance.) Done. The base element section should probably also talk about what happens when you modify the .href attribute. What more is there to say? Isn't it defined enough? On Fri, 2 Mar 2007, Keryx Web wrote: And today the base element already works in at least FFox and Opera also when content is sent as true XHTML 1.0, so this would not really change anything but the spec. Indeed. On Tue, 13 Mar 2007, Asbj�rn Ulsberg wrote: They don't conflict. They are both applied. base is the document's base URI, and xml:base is the base URI of the element it is applied on. What about: base href=http://www.example.org/; xml:base=/bar / The xml:base here has no effect. On Tue, 13 Mar 2007, Adrian Sutton wrote: I'm not entirely sure this is legal but what about (say for a document on http://localhost/): base href=.. xml:base=bar / On Tue, 10 Apr 2007, Jonas Sicking wrote: Note that the current text isn't implementable since it says that relative uris in base should be resolved against the base uri document, but the base element modifies that base uri so there is a circular dependency. No, the base element sets the document entity's base URI, and is resolved relative to the base URI from the encapsulating entity or the URI used to retrieve the entity. See RFC2396. On Wed, 14 Mar 2007, Bjoern Hoehrmann wrote: Note that some of the suggestions made in this thread would give quite surprising results e.g. when using XInclude. You didn't elaborate on what you considered surprising, so I can't tell if what the spec now says also suffers from these problems. Could you let me know if you think the spec as written would give surprising results when using XInclude, and which results it is you consider surprising? Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] classList.toggle()
Maciej Stachowiak wrote: How about about adding a toggle() operation to classList? Adds the token if not present, removes it if present. This would be useful for script code that dynamically manipulates classes to cause style changes. It's been my experience that toggles are troublesome. In order for a call to toggle() to be successful -- where by successful I mean that it makes the change you intended -- you need to know the state ahead of time. If you have two distinct scripts toggling the same value, they're going to get out of step and think they're turning on when they're turning off. Or did you have a use-case in mind where it doesn't matter what the end result is as long as it's not what it was before?
Re: [whatwg] Cue points in media elements
On 4/29/07, Brian Campbell [EMAIL PROTECTED] wrote: For the sort of content that we produce, cue points are incredibly important. Most of our content consists of a video or voiceover playing while bullet points appear, animations play, and graphics are revealed, all in sync with the video. We have a very simple system for doing cue points, that is extremely easy for the content authors to write and is robust for paused media, media that is skipped to the end, etc. We simply have a blocking call, WAIT, that waits until a specific point or the end of a specified media element. For instance, in our language, you might see something like this: (movie Foo.mov :name 'movie) (wait @movie (tc 2 3)) (show @bullet-1) (wait @movie) (show @bullet-2) If the user skips to the end of the media clip, that simply causes all WAITs on that media clip to return instantly. If they skip forward in the media clip, without ending it, all WAITs before that point will return instantly. If the user pauses the media clip, all WAITs on the media clip will block until it is playing again. This is a nice system, but I can't see how even as simple a system as this could be implemented given the current specification of cue points. The problem is that the callbacks execute when the current playback position of a media element reaches the cue point. It seems unclear to me what reaching a particular time means. If video playback freezes for a second, and so misses a cue point, is that considered to have been reached? Is there any way that you can guarantee that a cue point will be executed as long as video has passed a particular cue point? With a lot of bookkeeping and the timeupdate event along with the cue points, you may be able to keep track of the current time in the movie well enough to deal with the user skipping forward, pausing, and the video stalling and restarting due to running out of buffer. This doesn't address, as far as I can tell, issues like the thread displaying the video pausing for whatever reason and so skipping forward after it resumes, which may cause cue points to be lost, and which isn't specified to send a timeupdate event. Basically, what is necessary is a way to specify that a cue point should always be fired as long as playback has passed a certain time, not just if it reaches a particular time. This would prevent us from having to do a lot of bookkeeping to make sure that cue points haven't been missed, and make everything simpler and less fragile. In order to capture this kind of situations, with flexibility in mind, I think the concept of cue points may be changed to cue periods... Method names: addEnterCuePeriod(time1, time2, callback) removeEnterCuePeriod(time1, time2, callback) addLeaveCuePeriod(time1, time2, callback) removeLeaveCuePeriod(time1, time2, callback) The callback function mentioned by addEnterCuePeriod will be invoked once when the video enter the period of time bounded by time1 and time2. How the video get to a frame between time1 and time2 doesn't matter. i.e. the callback function may be invoked by a normally playing video reaching time1, a video being fast forward / wind back into the period between time1 time2, or a particular timing between time1 time2 of the video being directly seek for. The mechanism of LeaveCuePeriod is similar, while this time the callback is invoked when the video leave the specified cue period. (Or should this pair of methods left out?) With these four methods, one can not only achieve the bullet point effect, but also video captions appearance and disappearance. Hope this helps. 郁
Re: [whatwg] classList.toggle()
On May 1, 2007, at 12:05 AM, Martin Atkins wrote:
Maciej Stachowiak wrote:
How about about adding a toggle() operation to classList? Adds the
token if not present, removes it if present. This would be useful
for script code that dynamically manipulates classes to cause
style changes.
It's been my experience that toggles are troublesome. In order for
a call to toggle() to be successful -- where by successful I mean
that it makes the change you intended -- you need to know the state
ahead of time. If you have two distinct scripts toggling the same
value, they're going to get out of step and think they're turning
on when they're turning off.
Or did you have a use-case in mind where it doesn't matter what the
end result is as long as it's not what it was before?
Yes, cases where you have a UI action that is supposed to always
toggle the current state, and the class is used for styling so
appearance can't be out of sync with the state. Here's a simple
example. The images would zoom out and fade when you click on them,
and return to their normal state when clicked again.
style
.container {
margin: 75px;
}
.picture {
width: 50px;
height: 50px;
display: inline-block;
}
.picture img {
width: 50px;
height: 50px;
}
.picture.zoomed img {
width: 200px;
height: 200px;
position: relative;
left: -75px;
top: -75px;
opacity: 0.8;
}
/style
section class=container
h1Bridge Gallery/h1
div class=picture onclick=classList.toggle('zoomed')
img src=goden-gate-bridge.jpg
/div
div class=picture onclick=classList.toggle('zoomed')
img src=bay-bridge.jpg
/div
div class=picture onclick=classList.toggle('zoomed')
img src=san-mateo-bridge.jpg
/div
div class=picture onclick=classList.toggle('zoomed')
img src=benicia-bridge.jpg
/div
div class=picture onclick=classList.toggle('zoomed')
img src=dumbarton-bridge.jpg
/div
/section
Re: [whatwg] font (was Support Existing Content)
At 12:48 +1000 UTC, on 2007-05-01, Adrian Sutton wrote: [...] The only debate about what a WYSIWYG editor is on the web is between a very strict interpretation (it must look precisely like what you get) and the What You See Is What You Mean editors. That's one, yes. But also plenty of people don't even distinguish between the editor embedded within a publishing tool, and the publishing tool as a whole. So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will be taken to mean that any authoring tool is allowed to produce font. Anyway, I understand that there can be exceptional conditions (not that I'm convinced that this is one) that require that something that we don't really want is allowed in HTML after all. But I'm worried about setting the precedence that the source of a document can be decisive in whether or not it is conforming. Next could be to allow authors to whom CSS is too hard to abuse blockquote and table, or to consider a colour property conforming if the author isn't american. So what I'm saying is that, *if* font must be allowed, let's just plain allow it -- not only allow some authors to use it. I'm also worried about how allowing font would affect end users. What guarantee is there for end users that when they set their default and minimum font sizes, be it through User CSS or a GUI, that that one single setting will affect both font and CSS font rules? The term WYSIWYG really shouldn't be a concern for any reasonable person reading the spec. FWIW, my impression is that it is and will be. That's why at http://webrepair.org/ we avoid the term and instead say inline editor. Embedded editor might work too. Anyway, is the current phrasing intended to mean that an editor that 'is' not WYSIYWG, but *is* an editor, is not allowed to produce font? I've been working in this area for around 6 years now and I've never met anyone even semi-technical that didn't immediately understand the term WYSIWYG and know what it meant in terms of HTML editors. I'm surprised. My experience is that people take WYSIWYG in the original DTP meaning. Slapping that terminology onto the context of the Web confirms their misguided idea that that meaning of WYSIWYG applies to the Web. We cannot force authors of such tools to avoid that term, but I believe it is unwise to use the term in the spec. If you outlaw the font tag, you'll just get span style=font-family: ... instead which has no more semantic benefit and is far more difficult to work with. The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. As to span, can you explain exactly how span is much more difficult to work with, and for whom? That said, in general I recommend configuring the editor so it doesn't have a font menu and use predefined CSS styles instead Agreed. , but few people ever take that advice. Which people are you referring to? Authoring tool authors? Or the users of EditLive? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Cue points in media elements
On Apr 30, 2007, at 4:15 PM, Ralph Giles wrote: [On Apr 29, 2007, at 12:14 AM, Brian Campbell wrote:[ If video playback freezes for a second, and so misses a cue point, is that considered to have been reached? As I read it, cue points are relative to the current playback position, which does not advance if the stream buffer underruns, but it would if playback restarts after a gap, as might happen if the connection drops, or in an RTP stream. My proposal above would need to be amended to handle that case, and the decoder dropping frames...finding the right language here is hard. I believe that a cue point is reached if its time is traversed during playback. - Kevin
Re: [whatwg] font (was Support Existing Content)
The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. If I understand correctly, even that wouldn't be correct, because the only attribute specifically allowed on font is the style attribute. I don't personally know of any WYSIWYG editors that use font style. I know of some that use font color and font size as well as span style and even big and small, but none that use font style by default. As it is, it looks like the spec is trying to be backward compatible with something, but I don't know what. If font is allowed, then font size could be allowed, because a server-side script could more easily find font size=7 and replace it with h1. Since I'm not aware which editors are being graced by allowing font without size or color. Hopefully before editors start putting an HTML5 DOCTYPE on HTML files, they'll stop using font in favor of something else. Until then, they can happily put HTML 4.01 Transition (not even Strict!) on their documents that include font
Re: [whatwg] font (was Support Existing Content)
Jon Barnett writes: If font is allowed, then font size could be allowed, because a server-side script could more easily find font size=7 and replace it with h1. Why would that be a correct thing to do? If somebody has made text large for emphasis or other effect, then labelling it as a heading would be wrong, surely? Smylers
[whatwg] additional empty elements
I would like to know what other people think about
creating more empty elements in HTML5.
Say, for example, you have a website which has sections
of content that are indented variously. It would be easy
to accomplish the different styles using classes:
div class=firstgroupThis text isn't indented at
all!/div
div class=secondgroupThis text is indented a
little./div
div class=thirdgroupLots of
indentation./div
div class=firstgroupNo indentation here!/div
However, if I then wanted to add additional special
styling to the first and third div, (e.g.. a border and
background color) it is less graceful. I could add style
attributes, but that would be wasteful if I want to do
this on a large scale. Multiple classes would be
confusing.
A nice solution would be the addition of a few div tags.
(e.g. div2, div3, div4 and div5.) Then you could
do something like this:
style
div1 {text-indent:0px;}
div2 {text-indent:10px;}
div3 {text-indent:20px;}
/style
Then:
div1This text isn't indented at all!/div1
div2This text is indented a little./div2
div3Lots of indentation./div3
div1No indentation here!/div1
This is much more human-readable, and the addition of
additional styles is now elegant and easy with the use of
classes.
div1 class=bluestyleThis text isn't indented at
all!/div1
div2This text is indented a little./div2
div3 class=redstyleLots of
indentation./div3
div1No indentation here!/div1
I also think that it would simply be easier to write
code if there were a few extra non-semantic empty tags.
HTML5 needs improvements that will make people want to
use it. Making it easier to code than HTML 4 will ensure
a quicker and wider acceptance.
I am okay with the unimaginative numbering of the extra
elements, as it would make it easy to have a lot of new
elements. However, there are countless possibilities:
section, chunk, partition, block, enclosure,
zone, figure, sector, quadrant etc...
Are there other people who have found themselves wishing
for another span or div-like tag?
Brenton Strine
Re: [whatwg] additional empty elements
On Tue, 01 May 2007 21:21:20 +0200, Brenton Strine [EMAIL PROTECTED] wrote: A nice solution would be the addition of a few div tags. (e.g. div2, div3, div4 and div5.) Then you could do something like this: HTML is a language for markup meaningful by itself, not just as a hook for CSS. div2 doesn't mean anything. I am okay with the unimaginative numbering of the extra elements, as it would make it easy to have a lot of new elements. However, there are countless possibilities: section, chunk, partition, block, enclosure, zone, figure, sector, quadrant etc... This is something that WHATWG is already doing (section, footer etc), basing on the popularity of certain classnames found in the wild. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] additional empty elements
If you're marking up stuff as a tree, the markup should probably look like a
tree:
section id=treeFirst group
divSecond Group
divThird Group/div
/div
/section
if what you want it a tree, that structure is better, so the CSS would
simply say:
#tree, #tree div { margin-left: 5em; }
If you want to style each level differently, that's still easy to do without
making up class names:
#tree { background: blue; }
#tree div { background: green; }
#tree div div { background: yellow; }
Child selectors are not supported by IE6, but I believe they are by IE7 and
every other browser.
Re: [whatwg] additional empty elements
HTML is a language for markup meaningful by itself, not just as a hook for CSS. div2doesn't mean anything. That doesn't seem very practical to me. If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. If there weren't any CSS hooks, wouldn't people just (incorrectly) use other tags, like h1? I think that CSS and HTML are unbreakably connected. Brenton
Re: [whatwg] Cue points in media elements
On Apr 30, 2007, at 7:15 PM, Ralph Giles wrote: Thanks for adding to the discussion. We're very interested in implementing support for presentations as well, so it's good to hear from someone with experience. Thanks for responding, I'm glad to hear your input. On Sun, Apr 29, 2007 at 03:14:27AM -0400, Brian Campbell wrote: in our language, you might see something like this: (movie Foo.mov :name 'movie) (wait @movie (tc 2 3)) (show @bullet-1) (wait @movie) (show @bullet-2) If the user skips to the end of the media clip, that simply causes all WAITs on that media clip to return instantly. If they skip forward in the media clip, without ending it, all WAITs before that point will return instantly. How does this work if, for example, the user seeks forward, and then back to an earlier position? Would some of the 'show's be undone, or do they not seek backward with the media playback? We don't expose arbitrary seeking controls to our users; just play/ pause, skip forward back one card (which resets all state to a known value) and skip past the current video/audio (which just causes all waits on that media element to return instantly). Is the essential component of your system that all the shows be called in sequence to build up a display state, or that the last state trigger before the current playback point have been triggered? The former. Isn't this slow if a bunch of intermediate animations are triggered by a seek? Yes, though this is more a bug in our animation API (which could be taught to skip directly to the end of an animation when associated video/audio ends, but that just hasn't been done yet). Actually, that brings up another point, which is a bit more speculative. It may be nice to have a way to register a callback that will be called at animation rates (at least 15 frames/second or so) that is called with the current play time of a media element. This would allow you to keep animations in sync with video, even if the video might stall briefly, or seek forward or backward for whatever reason. We haven't implemented this in our current system (as I said, it still has the bug that animations still take their full time to play even when you skip video), but it may be helpful for this sort of thing. Does your system support live streaming as well? That complicates the design some when the presentation media updates appear dynamically. No, we only support progressive download. Anyway I think you could implement your system with the currently proposed interface by checking the current playback position and clearing a separate list of waits inside your timeupdate callback. I agree, it would be possible, but from my current reading of the spec it sounds like some cue points might be missed until quite a bit later (since timeupdate isn't guaranteed to be called every time anything discontinuous happens with the media). In general, having to do extra bookkeeping to keep track of the state of the media may be fragile, so stronger guarantees about when cue points are fired is better than trying to keep track of what's going on with timeupdate events. I agree this should be clarified. The appropriate interpretation should be when the current playback position reaches the frame corresponding to the queue point, but digital media has quantized frames, while the cue points are floating point numbers. Triggering all cue point callbacks between the last current playback position and the current one (including during seeks) would be one option, and do what you want as long as you aren't seeking backward. I'd be more in favor of triggering any cue point callbacks that lie between the current playback position and the current playback position of the next frame (audio frame for audio/ and video frame for video/ I guess). That means more bookkeeping to implement your system, but is less surprising in other cases. Sure, that would probably work. As I said, bookkeeping is generally a problem because it might get out of sync, but with stronger guarantees about when cue points are triggered, I think it could work. If video playback freezes for a second, and so misses a cue point, is that considered to have been reached? As I read it, cue points are relative to the current playback position, which does not advance if the stream buffer underruns, but it would if playback restarts after a gap, as might happen if the connection drops, or in an RTP stream. My proposal above would need to be amended to handle that case, and the decoder dropping frames...finding the right language here is hard. Yes, it's a tricky little problem. Our current system stays out of trouble because it makes quite a few simplifying assumptions (video is played forward only, progressive download, not streaming, etc). Obviously, in order to support a more general API, you're
Re: [whatwg] Cue points in media elements
On May 1, 2007, at 1:05 PM, Kevin Calhoun wrote: I believe that a cue point is reached if its time is traversed during playback. What does traversed mean in terms of (a) seeking across the cue point (b) playing in reverse (rewinding) and (c) the media stalling an restarting at a later point in the stream?
Re: [whatwg] additional empty elements
On 5/1/07, Brenton Strine [EMAIL PROTECTED] wrote: If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. An HTML document ought to make semantic sense, without regard to presentational information. The very definition of the separation of presentation from content is that the content should be authored without regard to how it will appear. That's not to say presentation is being eliminated, however; presentation simply should not be a consideration in how the content is authored. Ideally, anyway. If there weren't any CSS hooks, wouldn't people just (incorrectly) use other tags, like h1? I think that CSS and HTML are unbreakably connected. Indeed, one could say CSS is fundamentally dependent on HTML; the reverse is not true. Imagine a new technology came along to make HTML pretty: wouldn't it be nice if you didn't have to rewrite the HTML to service this new technology? As to folks using incorrect tags, well, what you're proposing isn't going to fix that. I think the supposition that multiple class names are confusing is flawed. What's wrong with saying div class=redtext indentmore (besides the fact that you'd want more useful, informative class names than redtext and indentmore)? By looking at it, someone could readily tell it's got the properties of both redtext and indentmore. In my estimation, being able to combine classes is one of the more powerful aspects of CSS. Dan Dorman
Re: [whatwg] font
At 12:47 -0500 UTC, on 2007-05-01, Jon Barnett wrote: [...] the only attribute specifically allowed on font is the style attribute. Whoops. Somehow I overlooked that. My bad. But given that, I *really* don't see the point of font anymore. I've searched the archive at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/ but can't find any discussion leading to http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#style0. Maybe Ian can explain where this entry in the spec comes from; what the rationale behind it is? [...] Hopefully before editors start putting an HTML5 DOCTYPE on HTML files, they'll stop using font in favor of something else. Until then, they can happily put HTML 4.01 Transition (not even Strict!) on their documents that include font From what I've seen typically these editors are used to edit fragments only. They don't generate doctype declarations or any part of the head. They are only used for (parts of) the body. Btw, that seems to show another aspect of the problem with rather undefined WYSIWYG editors I mentioned earlier: I don't believe it is common that an inline/embedded/whatever editor is in the position to generate a WYSIWYG signature through a meta element in the head. Typically that area of the document is controllled by the host application itself, not by the editor embedded in it. So for authoring tools to meet this requirement, both the host environments (CMSs and such) and the editors embedded in them would need to implement a common communication method. (Which would be very useful, for example to make it easier to embed conformance checkers. But that's another story.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] include element
Maciej Stachowiak wrote: On Apr 27, 2007, at 3:36 AM, Jonas Sicking wrote: Martin Atkins wrote: Christian Schmidt wrote: In practice, the result effect is often achieved by wrapping your include file in a document.write() and including this using script a script src= However, this makes it harder to write these includes by hand (you have to escape certain characters, ' \ \n \r \t), and debugging also gets more difficult. This last point made me think of a related issue: When you use the above technique, the included script runs in the security context of the including page, and this technique therefore requires complete trust of the included document. Would documents included via include run in the security context of the including page, as with the script technique, or would they run in the context of the included document, as with iframes? Personally I favor the latter, but I wonder if this impact's anyone's use-cases?. They would run in the context of the included page, just like an iframe. The processing of include is exactly that of iframe the only difference is in the rendering. In that case, wouldn't it make more sense to make in an attribute on iframe, or some setting of the CSS properties, instead of a whole different element? Different elements with identical processing model is a red flag, at least when the processing model is complex. Using iframe would be very nice from a security point of view. I've been trying to think about it from a semantic point of view to see if they are similar enough that using the same element would be ok, and I don't really feel strongly either way there. But since it solves the security problem it sounds like the way to go. One question I have is whether the include element would be limited to being a rectangular area, or if it could participate in inline flow, or act as multiple separate blocks that lay out independently. If the former, then I would suggest appropriate values of the CSS height and width properties make sense. If the latter, I think it could be pretty impractical to implement, and probably not worth the effort. Layout engines tend to assume that there is a CSS canvas and viewport at the root of the document and may not be prepared to inject content from another document into arbitrary points in the render tree. It would not be limited to rectangular areas and needs to take part of the main flow of the outer document. I do realize that this is non-trivial to implement, however I think it would be very valuable to users. Also, rendering content that lives in another document is something that implementations that plan on implementing XBL is going to have to implement anyway. In fact, if it is limited to same-site references as you suggest, I'm not sure what it really buys you over XMLHttpRequest and then setting innerHTML on the target element. The main advantage is ease of use. See my two examples in the original post where AJAX behaviours were done using basically a single statement of javascript (and not a single statement of XForms ;) ). Another advantage is the fact that the the content can stream in. Granted, this will be doable with XMLHttpRequest once progress events are implemented, but that requires yet again much more effort on the part of the developer. Additionally performance will never be as good since you'll have to reset .innerHTML multiple times. / Jonas
Re: [whatwg] Issues concerning the base element and xml:base
Ian Hickson wrote: On Sun, 11 Feb 2007, Geoffrey Sneddon wrote: Safari 2.0.4/419.3: (1) Inserted in DOM (in the innerHTML location). Firefox 2.0.0.1: (3) Inserted in DOM (in the innerHTML location). IE/Mac 5.2.3: (2) (anyway to view the DOM tree?) Opera 9.10: (1) DOM Snapshot for some reason isn't working. IE6/Win: (2) The new base never appears in DOM, but the full absolute URLs are in the DOM. IE7/Win: (3) The new base never appears in DOM, but the full absolute URLs are in the DOM. In conclusion, Safari and Opera change all the links, IE5/Mac and IE6/Win both change links within the fragment, and Firefox and IE7/Win don't change any links. The latter is the option I'm following for now. Note that browsers all do _different_ things for target= than for href=. The spec has made them act the same for now. I'm not sure this is workable, we'll have to see when the browser vendors try to get this interoperable. I can't imagine that it's a huge issue given that the browsers are so far from each other in terms of what they do here. I'm going to do a study of some subset of the Web to see how common this is (at least the static case; I can't really do much about the scripted case). I don't think this is a good solution actually. In general, I think it's good to always make the DOM reflect the behavior of the document. I.e. it shouldn't matter how you arrived to a specific DOM, be it through parsing of an incoming HTML stream, or by using DOM-Core calls. Whenever we make an exception for that rule I think we need to have a good reason for it. For quirky base behavior it is my experience that what matters most is what URI things in a static page is resolved against. Most modern pages that uses scripting and DOM and such usually only has zero or one base element that lives in the head. What I suggest is that we make the first or last base element in the head be the one that sets both the base target and the base href for the document (modulo all special handling needed when bases appear in the body, described below). While this is not what IE or Firefox does today, I doubt that it'll break enough pages to stray from the act-like-the-DOM-looks principal. Currently mozilla uses the last base that appears in head. There doesn't appear to be a reason for using the last rather than the first, it's just what we've always done. However it would be interesting to know what IE uses here since it might matter. Did safari or opera run into any issues here? One thing we unfortunately will have to deal with is base elements appearing in the middle of the body of the document. What mozilla had to do was once we find a base element in the body of the document, we tell the parser to remember the resolved href and/or target of that base element. We then for any element that uses base uris (full list at [1]) set an internal member in the element that hardcodes the elements base uri and/or base target. For elements that don't get this property set on them base href and target resolution works as normal. For elements that has this set base href and target resolution only uses the set properties. Note that you only set the saved href and target in the parser if the attribute is set in the base element. So if a document contains base target=foo in the middle of the body that does not set a saved href in the parser. This algorithm is something we had to add to firefox in order to support many pages out there. I think IE7 changed how they delt with this, though I don't know the specifics of how it changed. Would be interesting to get their feedback on this. [1]http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/document/src/nsHTMLContentSink.cpprev=3.787#799 On Tue, 10 Apr 2007, Jonas Sicking wrote: Note that the current text isn't implementable since it says that relative uris in base should be resolved against the base uri document, but the base element modifies that base uri so there is a circular dependency. No, the base element sets the document entity's base URI, and is resolved relative to the base URI from the encapsulating entity or the URI used to retrieve the entity. See RFC2396. Ah, the base part of base URI from the encapsulating entity confused me. Any chance we can remove that or is that the language RFC2396 uses? / Jonas
Re: [whatwg] font (was Support Existing Content)
On 2/5/07 1:28 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote: That's one, yes. But also plenty of people don't even distinguish between the editor embedded within a publishing tool, and the publishing tool as a whole. So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will be taken to mean that any authoring tool is allowed to produce font. I've honestly never come across anyone who did that. Interesting. So what I'm saying is that, *if* font must be allowed, let's just plain allow it -- not only allow some authors to use it. I would tend to agree with that sentiment. Having now heard that only the style attribute is currently allowed, the font tag is equivalent to span and there's no point in having it at all. The term WYSIWYG really shouldn't be a concern for any reasonable person reading the spec. FWIW, my impression is that it is and will be. That's why at http://webrepair.org/ we avoid the term and instead say inline editor. Embedded editor might work too. Embedded and inline editors would include the textarea tag, which is clearly not WYSIWYG for HTML (but is for plain text) so both are poor terms. I'm surprised. My experience is that people take WYSIWYG in the original DTP meaning. Slapping that terminology onto the context of the Web confirms their misguided idea that that meaning of WYSIWYG applies to the Web. We cannot force authors of such tools to avoid that term, but I believe it is unwise to use the term in the spec. I'd agree that people do take WYSIWYG in the original DTP meaning - that said, I've found that people aren't all that confident that what they see in Word will work cross-platform or look exactly the same when it prints anyway. It's probably not worth discussing this further here though. If you outlaw the font tag, you'll just get span style=font-family: ... instead which has no more semantic benefit and is far more difficult to work with. The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. Any good editor is already using h1 when they mean h1 and making it easy for users to apply it at the right time. I see no reason to believe that a developer who didn't care enough to support headings correctly will care about supporting HTML 5 down to the letter. As to span, can you explain exactly how span is much more difficult to work with, and for whom? Quite a number of the cheap HTML to PDF conversion processes don't support CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline CSS removed because of cross site scripting vulnerabilities (you can embed JavaScript in CSS and at least IE will execute it). That said, in general I recommend configuring the editor so it doesn't have a font menu and use predefined CSS styles instead Agreed. , but few people ever take that advice. Which people are you referring to? Authoring tool authors? Or the users of EditLive? The system administrators that configure the editor in whatever system they're using. Some people do restrict the editor to just applying predefined CSS classes and as a result they get a very consistent, easy to maintain site. Most however, prefer having the flexibility of a font menu so they can apply the specific font they won't precisely when they want it. Obviously I have more contact with users of EditLive! but I've seen this pattern with a huge range of editors. People want the editor to look and work like Microsoft Word and Word has a font menu. Regards, Adrian Sutton. __ Adrian Sutton, Integrations Product Manager Global Direct: +1 (650) 292 9659 x717 Australia: +61 (7) 3858 0118 UK +44 (20) 8123 0617 x717Mobile +61 (4) 222-36329 Ephox http://www.ephox.com/, Ephox Blogs http://planet.ephox.com/
Re: [whatwg] font (was Support Existing Content)
Embedded and inline editors would include the textarea tag, which is clearly not WYSIWYG for HTML (but is for plain text) so both are poor terms. Embedded, inline editors would include contenteditable areas and documents with designMode on, like the box I'm typing in right now in Gmail. Quite a number of the cheap HTML to PDF conversion processes don't support CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline CSS removed because of cross site scripting vulnerabilities (you can embed JavaScript in CSS and at least IE will execute it). It's not so much cheap as lightweight. A heavyweight converter can automate the process of opening a page in a browser window, print what's in the browser (more or less, some do more than just activate the browser's print function). A lightweight converter might natively try to interpret the HTML and try to render it as postscript. I think better solutions are coming along for the case of converting an HTML document to PDF in all its graphical glory on a server without X Window, etc. (e.g. a way of using Gecko to do the work without opening a window.) I don't think it's necessary to cater to these systems by allowing presentational markup.
Re: [whatwg] Cue points in media elements
Hearing about cue points in media elements. Just sorta reminds me of keyTimes in SMIL. I know SMIL seems funky to some people, but I do really love it! It is so way cool! So far as I know it doesn't do quite what you're talking about here, but it does similar stuff including non-linear distortions of timing elements and the like. It's declarative (though I don't think it's Turing complete -- wager of virtual beans proposed) and its syntax is worthy of emulation in that classical ontology recapitulates philology sort of sense. It is so much a W3C standard that it has six or eight or twelve standards devoted to it. David Dailey (who is trying to learn how not to re-invent wheels) http://srufaculty.sru.edu/david.dailey/copyright/dailey_on_copyright.htm Damn bastard mutant wheels keep popping up around me like unwanted copyrighted utterances in a world where intellectual landfills are charged by the bit! -- anonymous - Original Message - From: Brian Campbell [EMAIL PROTECTED] To: Ralph Giles [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 4:57 PM Subject: Re: [whatwg] Cue points in media elements On Apr 30, 2007, at 7:15 PM, Ralph Giles wrote: Thanks for adding to the discussion. We're very interested in implementing support for presentations as well, so it's good to hear from someone with experience. Thanks for responding, I'm glad to hear your input. On Sun, Apr 29, 2007 at 03:14:27AM -0400, Brian Campbell wrote: in our language, you might see something like this: (movie Foo.mov :name 'movie) (wait @movie (tc 2 3)) (show @bullet-1) (wait @movie) (show @bullet-2) If the user skips to the end of the media clip, that simply causes all WAITs on that media clip to return instantly. If they skip forward in the media clip, without ending it, all WAITs before that point will return instantly. How does this work if, for example, the user seeks forward, and then back to an earlier position? Would some of the 'show's be undone, or do they not seek backward with the media playback? We don't expose arbitrary seeking controls to our users; just play/ pause, skip forward back one card (which resets all state to a known value) and skip past the current video/audio (which just causes all waits on that media element to return instantly). Is the essential component of your system that all the shows be called in sequence to build up a display state, or that the last state trigger before the current playback point have been triggered? The former. Isn't this slow if a bunch of intermediate animations are triggered by a seek? Yes, though this is more a bug in our animation API (which could be taught to skip directly to the end of an animation when associated video/audio ends, but that just hasn't been done yet). Actually, that brings up another point, which is a bit more speculative. It may be nice to have a way to register a callback that will be called at animation rates (at least 15 frames/second or so) that is called with the current play time of a media element. This would allow you to keep animations in sync with video, even if the video might stall briefly, or seek forward or backward for whatever reason. We haven't implemented this in our current system (as I said, it still has the bug that animations still take their full time to play even when you skip video), but it may be helpful for this sort of thing. Does your system support live streaming as well? That complicates the design some when the presentation media updates appear dynamically. No, we only support progressive download. Anyway I think you could implement your system with the currently proposed interface by checking the current playback position and clearing a separate list of waits inside your timeupdate callback. I agree, it would be possible, but from my current reading of the spec it sounds like some cue points might be missed until quite a bit later (since timeupdate isn't guaranteed to be called every time anything discontinuous happens with the media). In general, having to do extra bookkeeping to keep track of the state of the media may be fragile, so stronger guarantees about when cue points are fired is better than trying to keep track of what's going on with timeupdate events. I agree this should be clarified. The appropriate interpretation should be when the current playback position reaches the frame corresponding to the queue point, but digital media has quantized frames, while the cue points are floating point numbers. Triggering all cue point callbacks between the last current playback position and the current one (including during seeks) would be one option, and do what you want as long as you aren't seeking backward. I'd be more in favor of triggering any cue point callbacks that lie between the current playback position and the current playback position of the next frame (audio frame for audio/ and
Re: [whatwg] Saying +1 or -1 is not useful on this mailing list
David Hyatt wrote: (ducks) +1 It is best to duck sometimes. Seems like I read that somewhere. If I could just remember it, now. Is there a special dispensation somewhere for those who would like to help write specs who are cursed with *really* bad memories? Oh and thanks for ducking. It helps my darts to avoid any accidental targets. *#$%^ cost of insurance these days. David Dailey
