Re: [whatwg] Client-side includes proposal
I have not bumped into any XSLT-related browser problems except for converting resource tree fragments to nodes which is unportable but it is needed in advanced applications only where you need recursion on document node construction. Anyway, my plan is to make the transformation a part of the publishing process, not a part of the rendering process; that is, you use your reliable XSLT driver to do the transformation and publish the result to the server. Clean, automatic and simple. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 18, 2008 7:57 PM To: Kristof Zelechovski Cc: 'WHAT working group' Subject: Re: [whatwg] Client-side includes proposal Kristof Zelechovski wrote: > Client-side includes make a document transformation, something which > logically belongs XSLT rather than HTML. And what would the workaround for > legacy browsers be? > Chris > You make good points but last I checked general browser and editor support for XSLT was abysmal. Everyone is saying its on their "roadmaps" though so maybe it will one day be reliable enough to use.
Re: [whatwg] Client-side includes proposal
I still get the feeling that this is an element that is being invented for the purpose of being invented and doesn’t solve any existing problem, or resolve any difficult to implement problems that are not already solved in layers below and above HTML. I worry slightly from this and similar proposals that certain parts of the spec will end up being deprecated in the next spec due to lack of use. With regards to instant AJAX for dummies, I struggle to accept that no-one is able to download an already existing javascript library that provides this functionality in a few simple lines. Maybe I've missed something but is there a mandate which sets out the audience HTML5 is trying to satisfy? Do we really need to reinvent the wheel? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: 19 August 2008 03:36 To: Greg Houston Cc: whatwg@lists.whatwg.org; Bill Wallace; João Eiras Subject: Re: [whatwg] Client-side includes proposal Greg Houston wrote: > On Mon, Aug 18, 2008 at 4:01 PM, João Eiras <[EMAIL PROTECTED]> wrote: >>> >>> >>> >> This is something that would probably not be represented with a new element, >> because elements are preserved in the DOM tree so they can be accessed and >> queried. >> So then you'd have a question: keep in the dom and allow access to >> children like an iframe, or replace entirely ? >> The answer could be intuitive, but that can open a can of worms. Then you >> can do all sorts of dynamic manipulation, which would have to be very well >> specified. >> I think the way to go would be a processing instruction. >> >> The idea is good though ! But I think could be better implemented with a css >> template like feature. I don't like the idea of a new element. >> >> Bye. > > This seems to be mostly useful for people creating small websites that > are afraid of server side scripting languages like PHP, Python and > Ruby. That being the case, if something like this is implemented the > included content should definitely not be accessed like with an > iframe. The elements included should be in the DOM tree of the parent > just as if the includes were done server side. Accessing the DOM of an > iframe from the parent and vice versa causes people a lot of > confusion. I don't think we need to add that level of confusion to the > group of users that would most likely use this feature. > > Also, a bonus of keeping in the > DOM, is that changing the source could reload the content of that > element. You would have instant AJAX/XHR for dummies. This is basically what i've suggested in a thread some months back. Basically an but that renders as if the inner was included inline. This is far from easy to implement since you have to do layout across several documents. But I think it would be a pretty useful feature to simplify AJAXy pages. If I ever get time I'm going to attempt an implementation in firefox which will hopefully provide experience to build a spec on. / Jonas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [whatwg] Client-side includes proposal
On Tue, 19 Aug 2008, Shannon wrote: > > You make a pretty big assumption here about the usage model of the > Internet being corporate + ISP. You ignore: > > * Local testing in WYSIWYG editors. WYSIWYG editors are quite capable of implementing a model whereby pages are merged before being previewed, and are merged when published, removing the need for any post-publication inclusion mechanism. > * Embedded servers in storage devices, media centers, routers and other > gadgets. > * Minimalist HTTP servers for simple usage, websocket tunnels or high load > services. > * Users taking advantage of free hosting services with limited features (like > Sourceforge or Geocities). > * Charities and OSS groups with better things to spend their money on than > hosting package upgrades. > * Companies like many in the building and equipment hire industries that spent > $500 on a website and call it expensive. In all of these cases, it is quite feasible to just pre-generate the documents with the includes directly in the content. > * Web applications and HTML documentation on the local filesystem. > * Autorun frontends on CDROM that are typically employed by magazine > coverdiscs. These aren't part of the use cases I am considering. > I assume that by "pre-generated" you're referring to > Dreamweaver/WebObjects templates rather than copy-and-paste. I was really thinking of C++ preprocessor includes, but any mechanism would be fine, sure. > I find these irritating as quite often you are given one format but > require another (as a FOSS user I can't/won't use Dreamweaver). I usually just roll my own using Perl, it's like one or two lines depending on what you want. > > We're talking about such a small amount of data here that the latency > > far outweighs the bandwidth cost on most connections. Given that you > > still have to do an If-Modified-Since check, you don't really gain > > anything here. > > I'm not sure where you get your statistics but these claims don't match > my direct experience. In the typical case a web page is heavily > dependant on included content such as CSS files, images, plugins and > other non-embedded elements. Even geek sites like orielly.com and > slashdot are not immune. According to websiteoptimization.com the > orielly home page has 60 external objects. Many common sites are even > worse. Your claim that adding HTML includes will have any noticeable > affect on overall page loading times needs more analysis. Most content doesn't require blocking. Those that require blocking (like scripts) are a massive problem. Just ask any browser vendor. Safari even ends up running a second tokeniser in parallel just to try to help this. > > > > > > > > > > > > > What do you do when the CSIed page includes script that manipulates > > content after the include? Now you have a race condition. This is just > > as bad as blocking, if not worse, since it's now unpredictable. > > You do the same thing you always have when external JS or inter-page > requests raise the same issue. External (blocking) JS is a disaster. We don't want to be adding more features like it. We're still trying to get out of the problems blocking scripts added. > > Anyway in conclusion I don't understand what CSIs give us that is > > actually worth the massive amounts of effort they require. Just > > generate your pages server-side or upload them to your server > > pre-generated. > > As a developer I tell you this is not really a good option, and I > disagree with your claim of "massive effort". It is a fairly > straightforward feature as they go. Embedded SQL is a massive effort, > WebWorkers is massive effort, client-side includes is quite trivial, > relatively speaking. Certainly worth further investigation in light of > its obvious benefits. Providing client-side includes in an efficient manner is on the same kind of scale as the other features you mention, but it doesn't have anywhere near the same level of benefit. IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Client-side includes proposal
Ian Hickson wrote: All three of the above basically boil down to the same thing -- there are hosting providers that don't provide the simplest of features. That's certainly true, but there are also hosting providers that provide these features for very cheap (e.g. $120/year or less) that provide all this and more, so I don't buy this argument. If you're having trouble finding one, contact me privately and I can give you a coupon code for one. Thank you but I have my own servers. You make a pretty big assumption here about the usage model of the Internet being corporate + ISP. You ignore: * Web applications and HTML documentation on the local filesystem. * Local testing in WYSIWYG editors. * Autorun frontends on CDROM that are typically employed by magazine coverdiscs. * Embedded servers in storage devices, media centers, routers and other gadgets. * Minimalist HTTP servers for simple usage, websocket tunnels or high load services. * Users taking advantage of free hosting services with limited features (like Sourceforge or Geocities). * Charities and OSS groups with better things to spend their money on than hosting package upgrades. * Companies like many in the building and equipment hire industries that spent $500 on a website and call it expensive. Far from being a small minority these groups and applications possibly make up the majority of HTML content after blogs. If it's just a static site, then you can just pre-generate the pages and upload the completed pages, so there's no dependency on the server. This, incidentally, also works when the server-side hosting provider doesn't support SSIs at all. If it's not a static site, then the SSIs are going to be the least of your problems when you change to a different server. I assume that by "pre-generated" you're referring to Dreamweaver/WebObjects templates rather than copy-and-paste. I find these irritating as quite often you are given one format but require another (as a FOSS user I can't/won't use Dreamweaver). Some of the best editors don't have any kind of template support and when they do it's typically native to the application. Sometimes they're even native to an installation (you can't export your templates). These things are bad for the web without some kind of accepted open specification. CSI could be that specification. Speed. Concerns about speed are generally only valid for the first page on the first visit to a site. Subsequent pages can be much faster than SSI and even static html since common banners and footers can be cached seperately - requiring only a unique content download. This is less trivial than it sounds since global drop-down menus, ad frames, tracking code, overlays and embedded JS and CSS often account for a vast majority of the source code. We're talking about such a small amount of data here that the latency far outweighs the bandwidth cost on most connections. Given that you still have to do an If-Modified-Since check, you don't really gain anything here. I'm not sure where you get your statistics but these claims don't match my direct experience. In the typical case a web page is heavily dependant on included content such as CSS files, images, plugins and other non-embedded elements. Even geek sites like orielly.com and slashdot are not immune. According to websiteoptimization.com the orielly home page has 60 external objects. Many common sites are even worse. Your claim that adding HTML includes will have any noticeable affect on overall page loading times needs more analysis. orielly.com: Total HTML: 5 Total HTML Images: 31 Total CSS Images: 14 Total Images: 45 Total Scripts: 7 Total CSS imports: 1 Total Frames: 0 Total Iframes: 4 report: http://www.websiteoptimization.com/services/analyze/wso.php?url=http://oreilly.com/ If we did want to optimise for small parts of the content being common over multiple pages, we should investigate dictionary-based compression with site-specific dictionaries. That would get us much, much better performance than cached CSIs. I like this idea, but it isn't an alternative to CSI from a designers perspective nor is it likely to have significant gains over current gzip implementations. This isn't an argument over SSIs. I agree that for inclusions, the seamless> feature isn't optimal. It was not designed for that, it was meant for including sandboxed blog comments and the like. I absolutely agree that iframes aren't an alternative to CSI, not vice-versa. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like . There is actually an easy solution for this, though it is less flexible than my original proposal. The solution is to require each include to be balanced (equal
Re: [whatwg] Client-side includes proposal
Greg Houston wrote: On Mon, Aug 18, 2008 at 4:01 PM, João Eiras <[EMAIL PROTECTED]> wrote: This is something that would probably not be represented with a new element, because elements are preserved in the DOM tree so they can be accessed and queried. So then you'd have a question: keep in the dom and allow access to children like an iframe, or replace entirely ? The answer could be intuitive, but that can open a can of worms. Then you can do all sorts of dynamic manipulation, which would have to be very well specified. I think the way to go would be a processing instruction. The idea is good though ! But I think could be better implemented with a css template like feature. I don't like the idea of a new element. Bye. This seems to be mostly useful for people creating small websites that are afraid of server side scripting languages like PHP, Python and Ruby. That being the case, if something like this is implemented the included content should definitely not be accessed like with an iframe. The elements included should be in the DOM tree of the parent just as if the includes were done server side. Accessing the DOM of an iframe from the parent and vice versa causes people a lot of confusion. I don't think we need to add that level of confusion to the group of users that would most likely use this feature. Also, a bonus of keeping in the DOM, is that changing the source could reload the content of that element. You would have instant AJAX/XHR for dummies. This is basically what i've suggested in a thread some months back. Basically an but that renders as if the inner was included inline. This is far from easy to implement since you have to do layout across several documents. But I think it would be a pretty useful feature to simplify AJAXy pages. If I ever get time I'm going to attempt an implementation in firefox which will hopefully provide experience to build a spec on. / Jonas
Re: [whatwg] Using as a source for canvas.drawImage
On Aug 18, 2008, at 5:58 PM, Robert O'Callahan wrote: On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote: Cool -- I wonder though if it would be better if it were placed in a different method, drawFrame or something (very much an up in the air sort of question) drawImage is already overloaded, so why not carry on with that, unless we change the API as you suggest below. I'm not sure that drawImage overloading was a good idea in the first place *but* canvas and image are fairly similar in both image-like, whereas video is quite clearly different. I was also thinking it would work better given the additional frame argument, however... AFAIK we'd basically have to implement that by creating a second video stream, seeking it and then capturing the frame, and you really don't want to do that synchronously! Then we'd want to cache that stream so that another drawFrame with a nearby frame index was efficient ... ick. So I suggest not offering that API. Authors can always use a second, hidden video element to achieve the same effect. ... I had failed to consider streaming content (where random seeking may not be possible) :-/ I still think it would be useful to be able to specify an exact frame, but as you say it may not be really feasible --Oliver
Re: [whatwg] overflow of seamless iframes
On Tue, Aug 19, 2008 at 1:05 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote: > On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > >> On Mon, 18 Aug 2008, Robert O'Callahan wrote: >> > >> > Suppose the iframe's document is >> > >> > What's the height of the bounding box? 400px or 500px? >> >> 500px. >> > > That's a little weird since only 400px of content will be displayed, but OK > as long as it's clear :-). > Hmm ... does the "bounding box" take into account scroll positions? Because if it does, then scrolling in the iframe's document can change the intrinsic height of the iframe (for example if there's also fixed-pos content in the iframe). That doesn't sound good. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] overflow of seamless iframes
On Tue, 19 Aug 2008, Robert O'Callahan wrote: > > But never mind about this issue anyway. I think we can live without it. Ok. As far as the spec goes, the current text is mostly a strawman proposal. I'm hoping to tweak it based on implementation experience. So, what I recommend is that you implement what you think is best, based on what the spec says, and then send us a report with your experience, suggesting changes to the spec as appropriate. The key use case that I want to make sure we address as far as seamless goes is the blog comments thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] overflow of seamless iframes
On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> >
> > Suppose the iframe's document is
> >
> > What's the height of the bounding box? 400px or 500px?
>
> 500px.
>
That's a little weird since only 400px of content will be displayed, but OK
as long as it's clear :-).
> > If we allow the contents to flow out of the box, then we also allow
> > > blog comments to start overlapping other content on the page.
> >
> > Yeah, although setting overflow:hidden on the iframe could be used to
> > prevent that.
>
> Fair enough. In that case I'd rather we had this in the UA stylesheet:
>
> iframe[seamless][sandbox] { overflow: hidden ! important; }
>
I'd suggest having that except without !important.
But never mind about this issue anyway. I think we can live without it.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Re: [whatwg] Using as a source for canvas.drawImage
On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > Cool -- I wonder though if it would be better if it were placed in a > different method, drawFrame or something (very much an up in the air sort of > question) > drawImage is already overloaded, so why not carry on with that, unless we change the API as you suggest below. One other thing that I would consider would be requiring the frame# to be > specified explicitly as that would make things like "chapter" previews (or > whatever) work in a way that is perhaps cleaner. Otherwise you have to > record the current location in the video stream, then scan to each location > you want to blit, draw, and then return to the original position. Which > could easily result in weird visual behaviour for the user (as the video > element flickers a few random frames while you do your previews or > whatever). > AFAIK we'd basically have to implement that by creating a second video stream, seeking it and then capturing the frame, and you really don't want to do that synchronously! Then we'd want to cache that stream so that another drawFrame with a nearby frame index was efficient ... ick. So I suggest not offering that API. Authors can always use a second, hidden video element to achieve the same effect. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] overflow of seamless iframes
On Mon, 18 Aug 2008, Robert O'Callahan wrote:
>
> Suppose the iframe's document is
>
> What's the height of the bounding box? 400px or 500px?
500px.
> > If we allow the contents to flow out of the box, then we also allow
> > blog comments to start overlapping other content on the page.
>
> Yeah, although setting overflow:hidden on the iframe could be used to
> prevent that.
Fair enough. In that case I'd rather we had this in the UA stylesheet:
iframe[seamless][sandbox] { overflow: hidden ! important; }
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Using as a source for canvas.drawImage
any suggestions as to what the equivalent would be for mapping audio tracks to filters defined elsewhere ? On Mon, Aug 18, 2008 at 2:45 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote: > Thanks to Anne for pointing this out... > > We've implemented using elements as an image source in > canvas.drawImage: > https://bugzilla.mozilla.org/show_bug.cgi?id=448674 > The extension is very obvious. Unlike animated images, which always draw > the first or poster frame, we draw the current frame of the video. This lets > you do things like make a thumbnail timeline. > > It'd be nice to have this in the spec. > > Rob > -- > "He was pierced for our transgressions, he was crushed for our iniquities; > the punishment that brought us peace was upon him, and by his wounds we are > healed. We all, like sheep, have gone astray, each of us has turned to his > own way; and the LORD has laid on him the iniquity of us all." [Isaiah > 53:5-6] >
Re: [whatwg] overflow of seamless iframes
It's not clear to me why "iframe { overflow: visible; }" won't do anything.
I've been involved in some web applications where the client uses iframes to
open different external applications in the main one and wanted it to grow
vertically so it doesn't have a vertical scroll.
Is there another way to achieve this without setting a fixed height and
without using javascript?
--
Samuel Santos
http://www.samaxes.com/
On Mon, Aug 18, 2008 at 9:53 AM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:
> On Mon, Aug 18, 2008 at 6:45 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
>> > On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> > > On Mon, 18 Aug 2008, Robert O'Callahan wrote:
>> > > > > Note that the default width and height are adjusted for seamless
>> > > > > iframes to match the width that the element would have if it was a
>> > > > > non-replaced block-level element with 'width: auto', and the
>> > > > > height of the bounding box around the content rendered in the
>> > > > > iframe at its current width, respectively.
>> > > >
>> > > > "The bounding box" is a bit ambiguous. If the content overflows
>> > > > vertically above the iframe's viewport, does that contribute to the
>> > > > height of the bounding box?
>> > >
>> > > As far as I can tell there is no ambiguity to the concept of the
>> > > bounding box of the content in the canvas, especially given the way
>> > > the initial containing block is forced to zero height.
>> >
>> > What's the answer to my question then? Should I have been able to derive
>> > it somehow?
>>
>> I don't understand the question. How does the viewport affect the bounding
>> box?
>
>
> Suppose the iframe's document is
>
> What's the height of the bounding box? 400px or 500px?
>
> I just thought of another problem with allowing the contents of a
>> "seamless" iframe to overflow outside the iframe box.
>>
>> One of the main uses for this will be to sandbox blog comments, using the
>> yet-to-be-defined doc="" attribute, as in:
>>
>> > seamless sandbox="allow-same-origin">
>>
>> If we allow the contents to flow out of the box, then we also allow blog
>> comments to start overlapping other content on the page.
>
>
> Yeah, although setting overflow:hidden on the iframe could be used to
> prevent that.
>
> > I'm concerned about the use case of very wide content in the iframe
>> > (i.e. content overflowing the root element horizontally); for example a
>> > forum with many wide messages, each of which is a seamless iframe. Right
>> > now it seems the choices are to either have a horizontal scrollbar in
>> > each message or clip each message horizontally, there's no way to make
>> > it work like a forum page.
>>
>> The way forum pages work now is that the content ends up screwing up the
>> rest of the page, so I think that's a good thing. :-) People work around
>> this now by forcing line break opportunities to exist in long URLs, etc,
>> or by setting overflow:auto on user-submitted content.
>
>
> Yes, although it would be nice to offer authors a choice. Oh well, I
> suppose it doesn't matter too much.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>
Re: [whatwg] Using as a source for canvas.drawImage
Cool -- I wonder though if it would be better if it were placed in a different method, drawFrame or something (very much an up in the air sort of question) One other thing that I would consider would be requiring the frame# to be specified explicitly as that would make things like "chapter" previews (or whatever) work in a way that is perhaps cleaner. Otherwise you have to record the current location in the video stream, then scan to each location you want to blit, draw, and then return to the original position. Which could easily result in weird visual behaviour for the user (as the video element flickers a few random frames while you do your previews or whatever). Just my 2c. --Oliver On Aug 18, 2008, at 2:45 PM, Robert O'Callahan wrote: Thanks to Anne for pointing this out... We've implemented using elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the video. This lets you do things like make a thumbnail timeline. It'd be nice to have this in the spec. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Using as a source for canvas.drawImage
Nice feature! That will be quite useful. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ On Mon, Aug 18, 2008 at 2:45 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote: > Thanks to Anne for pointing this out... > > We've implemented using elements as an image source in > canvas.drawImage: > https://bugzilla.mozilla.org/show_bug.cgi?id=448674 > The extension is very obvious. Unlike animated images, which always draw > the first or poster frame, we draw the current frame of the video. This lets > you do things like make a thumbnail timeline. > > It'd be nice to have this in the spec. > > Rob > -- > "He was pierced for our transgressions, he was crushed for our iniquities; > the punishment that brought us peace was upon him, and by his wounds we are > healed. We all, like sheep, have gone astray, each of us has turned to his > own way; and the LORD has laid on him the iniquity of us all." [Isaiah > 53:5-6] >
Re: [whatwg] Client-side includes proposal
On Mon, Aug 18, 2008 at 4:36 PM, Greg Houston <[EMAIL PROTECTED]>wrote: > This seems to be mostly useful for people creating small websites that > are afraid of server side scripting languages like PHP, Python and > Ruby. I'm really going to have to point at this. If your server provider doesn't include PHP or something similar, there's something wrong. There are *tons* of dirt-cheap providers that do. Using, say, PHP doesn't even require anyone to *learn* anything. The example from the original email would simply be: --- Master Document --- Include Example http://www.pagelets.com/foo.ihtml";; ?> --- Header.html --- Header You can even do html fragments or attributes. There's literally nothing to learn over the current proposal, but this works right now in virtually every host and doesn't depend on the user's browser. ~TJ
Re: [whatwg] Client-side includes proposal
On Mon, Aug 18, 2008 at 9:54 AM, Kristof Zelechovski wrote: > And what would the workaround for legacy browsers be? AJAX? e.g. http://www.mnot.net/javascript/hinclude/ -- Thomas Broyer
Re: [whatwg] Client-side includes proposal
On Mon, 18 Aug 2008, Bill Wallace wrote: > > It is only expensive if the client needs to do the client side include > each time - however, if the page re-uses parts all the time, then parts > of the page can be cached either in a proxy or directly client side, and > that can make it faster as well as reducing server load. Consider > including 3-4 components: > > > > > > This type of page needs to be read at least a couple of times for each > client for it to be faster, but there are lots of clients like that. This still ends up being expensive due to the round-trip cost of checking if the resource has changed or not, even if the resource itself isn't transferred. It's cheaper to just include the content. If we wanted to optimise this case, we should look into dictionary-based compression. > HOWEVER - how about just using the xlink design and making it part of > the html standard (allowing HTML fragments to be included, not just > XML). That has client side includes, and also supports client side > replacement of components based on clicking a URL/button/object. > Supporting xlink in html consistently would allow most of the current > JavaScript based applications to be replaced with JavaScript free > applications, and that would make many of them much safer, and is > reasonably efficient. I assume you mean XInclude, not XLink (XLink is a disaster). Certainly if people want to use XInclude with XHTML there's nothing in the HTML5 spec that stops it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Using as a source for canvas.drawImage
Thanks to Anne for pointing this out... We've implemented using elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the video. This lets you do things like make a thumbnail timeline. It'd be nice to have this in the spec. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Client-side includes proposal
On Tue, 19 Aug 2008, Shannon wrote: > > > > What advantage does this have over server-side includes? > > Cost. SSI of any description generally puts you on a "business" hosting > plan with a cost increase of up to 10x. Client-side includes only > require static page serving which can also be beneficial where the > server is a device (like a router interface). > > Availability. As far as I can tell SSI is only available on Apache and > later versions of IIS. This may be a market majority but when you > consider the number of devices and "home servers" coming onto the market > with basic web interfaces the actual availability of SSI may be lower > than you'd expect. > > Security. Availability is reduced even further by ISP and organisations > that flat-out refuse to support SSI due to security and support > concerns. All three of the above basically boil down to the same thing -- there are hosting providers that don't provide the simplest of features. That's certainly true, but there are also hosting providers that provide these features for very cheap (e.g. $120/year or less) that provide all this and more, so I don't buy this argument. If you're having trouble finding one, contact me privately and I can give you a coupon code for one. > Reuse. SSI follows no agreed set of rules and therefore may require code > changes when changing hosting provider. Some systems provide extensions > that authors may assume is part of a standard, but aren't. We have an > opportunity to define a simpler and more reliable interface that is > independant of any server configuration. If it's just a static site, then you can just pre-generate the pages and upload the completed pages, so there's no dependency on the server. This, incidentally, also works when the server-side hosting provider doesn't support SSIs at all. If it's not a static site, then the SSIs are going to be the least of your problems when you change to a different server. > Speed. Concerns about speed are generally only valid for the first page > on the first visit to a site. Subsequent pages can be much faster than > SSI and even static html since common banners and footers can be cached > seperately - requiring only a unique content download. This is less > trivial than it sounds since global drop-down menus, ad frames, tracking > code, overlays and embedded JS and CSS often account for a vast majority > of the source code. We're talking about such a small amount of data here that the latency far outweighs the bandwidth cost on most connections. Given that you still have to do an If-Modified-Since check, you don't really gain anything here. If we did want to optimise for small parts of the content being common over multiple pages, we should investigate dictionary-based compression with site-specific dictionaries. That would get us much, much better performance than cached CSIs. > Flexibility. It's hard to tell because the seamless proposal is vague > but from what I can tell there are a lot of things a "seamless" iframe > is not seamless about. For instance can absolutely positioned items be > positioned relative to the enclosing document? Do child and adjacent > selectors work across the iframe boundary? Will IE give up its behaviour > of placing iframes above the document regardless of z-index? Includes > don't have any of these issues because they are treated as part of the > document, not as a special case. This isn't an argument over SSIs. I agree that for inclusions, the feature isn't optimal. It was not designed for that, it was meant for including sandboxed blog comments and the like. > > A TCP round-trip is very expensive. A client-side parsing-level > > include would mean that the parser would have to stop while a complete > > round-trip is performed. There's really no way to get around that > > short of making it a higher-level construct like . > > There is actually an easy solution for this, though it is less flexible > than my original proposal. The solution is to require each include to be > balanced (equal number of open and close tags) so the surrounding block > is guaranteed to be a single node. Anything left open is forcefully > closed (as when reaching with open blocks). In other words: > > > > What do you do when the CSIed page includes script that manipulates content after the include? Now you have a race condition. This is just as bad as blocking, if not worse, since it's now unpredictable. Anyway in conclusion I don't understand what CSIs give us that is actually worth the massive amounts of effort they require. Just generate your pages server-side or upload them to your server pre-generated. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Client-side includes proposal
On Mon, Aug 18, 2008 at 4:01 PM, João Eiras <[EMAIL PROTECTED]> wrote: >> >> >> > > This is something that would probably not be represented with a new element, > because elements are preserved in the DOM tree so they can be accessed and > queried. > So then you'd have a question: keep in the dom and allow access to > children like an iframe, or replace entirely ? > The answer could be intuitive, but that can open a can of worms. Then you > can do all sorts of dynamic manipulation, which would have to be very well > specified. > I think the way to go would be a processing instruction. > > The idea is good though ! But I think could be better implemented with a css > template like feature. I don't like the idea of a new element. > > Bye. This seems to be mostly useful for people creating small websites that are afraid of server side scripting languages like PHP, Python and Ruby. That being the case, if something like this is implemented the included content should definitely not be accessed like with an iframe. The elements included should be in the DOM tree of the parent just as if the includes were done server side. Accessing the DOM of an iframe from the parent and vice versa causes people a lot of confusion. I don't think we need to add that level of confusion to the group of users that would most likely use this feature. Also, a bonus of keeping in the DOM, is that changing the source could reload the content of that element. You would have instant AJAX/XHR for dummies. - Greg
Re: [whatwg] implicitly invoke the load() method
On Mon, 18 Aug 2008, Philip J�genstedt wrote:
>
> Now consider this markup
>
>
>
> with this script dynamically changing the sources
>
> video = document.getElementById("video");
> video.removeAttribute("src"); // implicit delayed load
> source = document.createElement("source");
> source.src = "bar";
> source.media = "projection";
> video.appendChild(source); // implicit delayed load
> source = document.createElement("source");
> source.src = "baz";
> source.media = "screen";
> video.appendChild(source); // implicit delayed load
> video.play() // i want to play now!
>
> play() will call load() before returning, so after this has finished
> there shouldn't be any need to load() any more. However, there is no
> less than 3 calls to load() waiting. Playback will begin, but will stop
> as soon as the first of those delayed loads are invoked.
Fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Client-side includes proposal
This is something that would probably not be represented with a new element, because elements are preserved in the DOM tree so they can be accessed and queried. So then you'd have a question: keep in the dom and allow access to children like an iframe, or replace entirely ? The answer could be intuitive, but that can open a can of worms. Then you can do all sorts of dynamic manipulation, which would have to be very well specified. I think the way to go would be a processing instruction. The idea is good though ! But I think could be better implemented with a css template like feature. I don't like the idea of a new element. Bye.
Re: [whatwg] Client-side includes proposal
It is only expensive if the client needs to do the client side include each time - however, if the page re-uses parts all the time, then parts of the page can be cached either in a proxy or directly client side, and that can make it faster as well as reducing server load. Consider including 3-4 components: This type of page needs to be read at least a couple of times for each client for it to be faster, but there are lots of clients like that. HOWEVER - how about just using the xlink design and making it part of the html standard (allowing HTML fragments to be included, not just XML). That has client side includes, and also supports client side replacement of components based on clicking a URL/button/object. Supporting xlink in html consistently would allow most of the current JavaScript based applications to be replaced with JavaScript free applications, and that would make many of them much safer, and is reasonably efficient. 2008/8/18 Martin Ellis <[EMAIL PROTECTED]> > I can't speak for non Windows/Linux users, but for windows users IIS > comes supplied and supports SSI, asp.net php (via a download) etc and > with linux you can download apache and a sluth of other http daemons, I > see no reason for any html page to require the client to do the inline > including of content, as stated previously in this thread the tcp > overhead is huge and this would only make it worse in my opinion. > > M > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Shannon > Sent: 18 August 2008 18:57 > To: Kristof Zelechovski > Cc: 'WHAT working group' > Subject: Re: [whatwg] Client-side includes proposal > > Kristof Zelechovski wrote: > > Client-side includes make a document transformation, something which > > logically belongs XSLT rather than HTML. And what would the > workaround for > > legacy browsers be? > > Chris > > > > You make good points but last I checked general browser and editor > support for XSLT was abysmal. Everyone is saying its on their "roadmaps" > > though so maybe it will one day be reliable enough to use. > > You could go: > > >Banner > > > But this just seems wasteful, pointless and open to abuse. I think a > better workaround is that people with legacy browsers download each > include file seperately and paste them together in DOS or AmigaOS or > whatever system it is that keeps them from installing a modern browser. > > Of course XSLT has the same legacy issues as do many parts of HTML5. I > know the reasoning but at some point the web will have to leave > unmaintained software behind or face the same grim reality OpenGL is > facing now (can't move forward because a minority want legacy support > for 10 year old CAD applications, can't go back because competing > protocols are in front on features). > > I'd like to see the option made available and its use determined by the > market as we have always done. If a developer wants to piss-off users by > > writing a Flash or Silverlight-only website then the ONLY thing we can > do is provide an equivalent feature and hope that it does less harm (by > virtue of being a truly open standard). The average web developer's > mentally is very different from the majority of this list, they won't > compromise to do the "right thing". If I can do client-side includes in > Flash and Silverlight (and I can) then why should HTML be left behind? > > Anyway, I don't mean for an open discussion on this as I'm sure it's > been debated endlessly. I'm just stating my case for going ahead with > this feature. > > Shannon > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > >
Re: [whatwg] Client-side includes proposal
I can't speak for non Windows/Linux users, but for windows users IIS comes supplied and supports SSI, asp.net php (via a download) etc and with linux you can download apache and a sluth of other http daemons, I see no reason for any html page to require the client to do the inline including of content, as stated previously in this thread the tcp overhead is huge and this would only make it worse in my opinion. M -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: 18 August 2008 18:57 To: Kristof Zelechovski Cc: 'WHAT working group' Subject: Re: [whatwg] Client-side includes proposal Kristof Zelechovski wrote: > Client-side includes make a document transformation, something which > logically belongs XSLT rather than HTML. And what would the workaround for > legacy browsers be? > Chris > You make good points but last I checked general browser and editor support for XSLT was abysmal. Everyone is saying its on their "roadmaps" though so maybe it will one day be reliable enough to use. You could go: Banner But this just seems wasteful, pointless and open to abuse. I think a better workaround is that people with legacy browsers download each include file seperately and paste them together in DOS or AmigaOS or whatever system it is that keeps them from installing a modern browser. Of course XSLT has the same legacy issues as do many parts of HTML5. I know the reasoning but at some point the web will have to leave unmaintained software behind or face the same grim reality OpenGL is facing now (can't move forward because a minority want legacy support for 10 year old CAD applications, can't go back because competing protocols are in front on features). I'd like to see the option made available and its use determined by the market as we have always done. If a developer wants to piss-off users by writing a Flash or Silverlight-only website then the ONLY thing we can do is provide an equivalent feature and hope that it does less harm (by virtue of being a truly open standard). The average web developer's mentally is very different from the majority of this list, they won't compromise to do the "right thing". If I can do client-side includes in Flash and Silverlight (and I can) then why should HTML be left behind? Anyway, I don't mean for an open discussion on this as I'm sure it's been debated endlessly. I'm just stating my case for going ahead with this feature. Shannon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [whatwg] Client-side includes proposal
Kristof Zelechovski wrote: Client-side includes make a document transformation, something which logically belongs XSLT rather than HTML. And what would the workaround for legacy browsers be? Chris You make good points but last I checked general browser and editor support for XSLT was abysmal. Everyone is saying its on their "roadmaps" though so maybe it will one day be reliable enough to use. You could go: Banner But this just seems wasteful, pointless and open to abuse. I think a better workaround is that people with legacy browsers download each include file seperately and paste them together in DOS or AmigaOS or whatever system it is that keeps them from installing a modern browser. Of course XSLT has the same legacy issues as do many parts of HTML5. I know the reasoning but at some point the web will have to leave unmaintained software behind or face the same grim reality OpenGL is facing now (can't move forward because a minority want legacy support for 10 year old CAD applications, can't go back because competing protocols are in front on features). I'd like to see the option made available and its use determined by the market as we have always done. If a developer wants to piss-off users by writing a Flash or Silverlight-only website then the ONLY thing we can do is provide an equivalent feature and hope that it does less harm (by virtue of being a truly open standard). The average web developer's mentally is very different from the majority of this list, they won't compromise to do the "right thing". If I can do client-side includes in Flash and Silverlight (and I can) then why should HTML be left behind? Anyway, I don't mean for an open discussion on this as I'm sure it's been debated endlessly. I'm just stating my case for going ahead with this feature. Shannon
Re: [whatwg] Client-side includes proposal
Ian Hickson wrote: On Mon, 18 Aug 2008, Shannon wrote: The discussion on seamless iframes reminded me of something I've felt was missing from HTML - an equivalent client functionality to server-side includes as provided by PHP, Coldfusion and SSI. What advantage does this have over server-side includes? The idea has the advantage of not blocking rendering, which a client-side parsing-level include would. I don't really see what the advantage of a client-side parsing-level include would be. Cost. SSI of any description generally puts you on a "business" hosting plan with a cost increase of up to 10x. Client-side includes only require static page serving which can also be beneficial where the server is a device (like a router interface). Availability. As far as I can tell SSI is only available on Apache and later versions of IIS. This may be a market majority but when you consider the number of devices and "home servers" coming onto the market with basic web interfaces the actual availability of SSI may be lower than you'd expect. Security. Availability is reduced even further by ISP and organisations that flat-out refuse to support SSI due to security and support concerns. Reuse. SSI follows no agreed set of rules and therefore may require code changes when changing hosting provider. Some systems provide extensions that authors may assume is part of a standard, but aren't. We have an opportunity to define a simpler and more reliable interface that is independant of any server configuration. Speed. Concerns about speed are generally only valid for the first page on the first visit to a site. Subsequent pages can be much faster than SSI and even static html since common banners and footers can be cached seperately - requiring only a unique content download. This is less trivial than it sounds since global drop-down menus, ad frames, tracking code, overlays and embedded JS and CSS often account for a vast majority of the source code. Flexibility. It's hard to tell because the seamless proposal is vague but from what I can tell there are a lot of things a "seamless" iframe is not seamless about. For instance can absolutely positioned items be positioned relative to the enclosing document? Do child and adjacent selectors work across the iframe boundary? Will IE give up its behaviour of placing iframes above the document regardless of z-index? Includes don't have any of these issues because they are treated as part of the document, not as a special case. Even with these advantages I do not believe it is an either/or case. "seamless" iframes serve a purpose too and I do not want to see them dropped from the spec. I would however like to see more clarity in the spec as to how they interact with scripts and styles (especially adjacency selectors) in the master document and neighbouring seamless frames. HTTP 1.1 pipelining should remove any performance concerns that includes would have over traditional SSI since the retrieval process only requires the sending of a few more bytes of request and response headers. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like . There is actually an easy solution for this, though it is less flexible than my original proposal. The solution is to require each include to be balanced (equal number of open and close tags) so the surrounding block is guaranteed to be a single node. Anything left open is forcefully closed (as when reaching with open blocks). In other words: Since we know "content" is a closed block we can draw in a transparent placeholder and continue rendering the outer document as we do with img, video, iframes and embed. Once the true dimensions are known the renderer can repaint as it does with table cells and other "auto" sizing. This will often improve the readability of documents on slower connections since the top third of source code is usually concerned with banners, menus, search-bars and other cruft not directly relevant to the content the user wants to view and this is exactly the stuff you would want to put in an include to begin with. If it renders last then all the better. Shannon
[whatwg] implicitly invoke the load() method
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#load
There are a number of conditions for media elements where the user agent
"must implicitly invoke the load() method on the media element as soon
as all other scripts have finished executing":
* a source element is inserted into a media element that is already in a
document and whose networkState is in the EMPTY state
* the src attribute of a media element that is already in a document and
whose networkState is in the EMPTY state is added, changed, or removed
* a media element whose networkState has the value EMPTY is inserted
into a document
Now consider this markup
with this script dynamically changing the sources
video = document.getElementById("video");
video.removeAttribute("src"); // implicit delayed load
source = document.createElement("source");
source.src = "bar";
source.media = "projection";
video.appendChild(source); // implicit delayed load
source = document.createElement("source");
source.src = "baz";
source.media = "screen";
video.appendChild(source); // implicit delayed load
video.play() // i want to play now!
play() will call load() before returning, so after this has finished
there shouldn't be any need to load() any more. However, there is no
less than 3 calls to load() waiting. Playback will begin, but will stop
as soon as the first of those delayed loads are invoked.
I believe that the spec actually may allow the N implicit loads to be
treated as 1, but at the very least there must be that 1, which is still
too many in this case. I doubt many authors will realize all the things
which may cause an implicit load, so I think the spec needs to allow for
this to be made simpler (from the script author's point of view). More
importantly, there's absolutely no need to implicitly call load once its
been explicitly called once.
I would suggest the following solution:
If when the time comes to invoke the load() method it has already been
invoked (directly or via another implicit invocation triggered by the
same script) then don't call it again.
Comments? I'm not sure exactly how to change the spec, but if we agree
that this needs fixing we can come back to that.
--
Philip Jägenstedt
Opera Software
Re: [whatwg] overflow of seamless iframes
On Mon, Aug 18, 2008 at 6:45 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > > > > Note that the default width and height are adjusted for seamless > > > > > iframes to match the width that the element would have if it was a > > > > > non-replaced block-level element with 'width: auto', and the > > > > > height of the bounding box around the content rendered in the > > > > > iframe at its current width, respectively. > > > > > > > > "The bounding box" is a bit ambiguous. If the content overflows > > > > vertically above the iframe's viewport, does that contribute to the > > > > height of the bounding box? > > > > > > As far as I can tell there is no ambiguity to the concept of the > > > bounding box of the content in the canvas, especially given the way > > > the initial containing block is forced to zero height. > > > > What's the answer to my question then? Should I have been able to derive > > it somehow? > > I don't understand the question. How does the viewport affect the bounding > box? Suppose the iframe's document is What's the height of the bounding box? 400px or 500px? I just thought of another problem with allowing the contents of a > "seamless" iframe to overflow outside the iframe box. > > One of the main uses for this will be to sandbox blog comments, using the > yet-to-be-defined doc="" attribute, as in: > > seamless sandbox="allow-same-origin"> > > If we allow the contents to flow out of the box, then we also allow blog > comments to start overlapping other content on the page. Yeah, although setting overflow:hidden on the iframe could be used to prevent that. > I'm concerned about the use case of very wide content in the iframe > > (i.e. content overflowing the root element horizontally); for example a > > forum with many wide messages, each of which is a seamless iframe. Right > > now it seems the choices are to either have a horizontal scrollbar in > > each message or clip each message horizontally, there's no way to make > > it work like a forum page. > > The way forum pages work now is that the content ends up screwing up the > rest of the page, so I think that's a good thing. :-) People work around > this now by forcing line break opportunities to exist in long URLs, etc, > or by setting overflow:auto on user-submitted content. Yes, although it would be nice to offer authors a choice. Oh well, I suppose it doesn't matter too much. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Client-side includes proposal
Client-side includes make a document transformation, something which logically belongs XSLT rather than HTML. And what would the workaround for legacy browsers be? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 18, 2008 8:34 AM To: WHAT working group Subject: [whatwg] Client-side includes proposal The proposal would work like this: --- Master Document --- Include Example http://www.pagelets.com/foo.ihtml";> --- Header.html --- Header
Re: [whatwg] Client-side includes proposal
On Mon, 18 Aug 2008, Shannon wrote: > > The discussion on seamless iframes reminded me of something I've felt > was missing from HTML - an equivalent client functionality to > server-side includes as provided by PHP, Coldfusion and SSI. In > server-side includes the document generated from parts appears as a > single entity rather than nested frames. In other words the source code > seen by the UA is indistiguishable from a non-frames HTML page in every > way. What advantage does this have over server-side includes? The idea has the advantage of not blocking rendering, which a client-side parsing-level include would. I don't really see what the advantage of a client-side parsing-level include would be. > The other issue with iframes is that for many page snippets the concept > of a title, meta tags and other headers don't make sense or simply > repeat what was in the main document. More often than not the > section is meaningless yet must still be included for the frame to be > "well-formed" or indexed by spiders. Yeah, I've been considering making the element optional for documents that aren't meant to be navigated to directly, like includes. > HTTP 1.1 pipelining should remove any performance concerns that includes > would have over traditional SSI since the retrieval process only > requires the sending of a few more bytes of request and response > headers. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like . -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
