Re: [whatwg] Non-blocking SVG Canvas?
> > First off, where would be an appropriate area to continue this conversation? > > Here is probably fine, unless you want one of www-st...@w3.org or > www-...@w3.org. > > > I'm guessing the discussion is becoming less relevant to the HTML5 spec... > > But this isn't an HTML5 spec list... It's a whatwg spec list (which > includes a lot more than HTML5). Thank you for that. I was a little bit unsure of myself... whether I should discuss this here or not. If there's no issues, I guess I can continue here. :) > > * Why do browsers do this? Is there somewhere in the specs that says empty > > (the transparent areas of) svg tags embedded inside another svg tag should > > "act like they do not exist"? > > One could interpret section 16.4 of the SVG 1.1 specification as saying > this, maybe. I'm not sure whether any UAs actually implement that (in > particular dropping on the floor events with no graphic element under > them in SVG documents). Webkit and Opera certainly trigger the event > handler for a click anywhere in the viewport given this SVG document: Interesting point. I've poured through several pages of the SVG spec to see if there was anywhere that would give some insight on what to do. See if I'm reasoning this out correctly. The SVG spec takes special effort to differentiate between the base SVG tag and nested SVG tags. You can have an SVG document that has a proper mime type and the topmost element is the svg tag. This has special clipping rules. On the other hand if you have an SVGFragment that is part of a greater xml, html, etc... document that is in another namespace, then there is special negotiation rules for clipping. The point is that the SVG spec takes some effort to differentiate between how SVG documents and and embedded SVG is handled in terms of clipping However, I find no such clarity when it comes to events. -- events -- 16.4 "For each pointer event, the SVG user agent determines the target element of a given pointer event. The target element is the topmost graphics element whose relevant graphical content is under the pointer at the time of the event." "target element is .. topmost graphics element" graphics element = "One of the element types that can cause graphics to be drawn onto the target canvas. Specifically: ‘circle’, ‘ellipse’, ‘image’, ‘line’, ‘path’, ‘polygon’, ‘polyline’, ‘rect’, ‘text’ and ‘use’." (http://www.w3.org/TR/SVG11/intro.html#TermGraphicsElement) Based on this, it would almost seem like svg events should not trigger on the base svg tag (when it is transparent), because there is no graphics element to receive the event. Of course, we know that the browsers do not do this. At this point, my question would be was this done not because it was in the spec, but because it seemed reasonable? ... Or is the problem that we are both misunderstanding the SVG spec? --- No special mention of svg & non-svg interaction for events --- Once again, going back to 16.4, it continues with: "(See property ‘pointer-events’ for a description of how to determine whether an element's relevant graphical content is under the pointer, and thus in which circumstances that graphic element can be the target element for a pointer event.)" Unlike when the spec deals with clipping, there is never a specific area that talks about how events between a non-svg namespace and the svg namespace should react. --- my opinion? --- Based on the limited info, it almost seems like the spec says that events should NOT trigger for the base svg tag (if it has no graphical content). Even if it is a .svg file, the event should just "fall through" as you called it. This is of course, not how browsers do it. However, ignoring browsers for a second... if this is really what the specs suggest then the logical conclusion for HTML (with an svg tag in it) would be that events should drop through the transparent base svg to the underlying HTML 5 content/document. I think I would really like to get some input from people who have done some work on the SVG spec. :) Kevin
Re: [whatwg] Timed tracks for
Hi Ian, I think there's a typo in the description of the TimedTrack mode at http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#timed-track-mode. It says: Hidden Indicates that the timed track is active, but that the user agent is not actively displaying the cues. If no attempt has yet been made to obtain the track's cues, the user will perform such an attempt momentarily. The user agent is maintaining a list of which cues are active, and events are being fired accordingly. But I think it should be "the user *agent* will perform such an attempt momentarily." Cheers, Silvia.
Re: [whatwg] IDL attribute reflecting enumerated attributes not limited to only know values
On 08/06/2010 09:01 PM, Ian Hickson wrote: >> - input.autocomplete: at the moment, it is returning the content but it >> could return the resulting autocompletion state which is maybe a bit >> more than just being limited to only known values but still in the same >> spirit. > > I haven't changed this; what's the use case for knowing the actual state? Theoretically speaking, I think input.autocomplete should return the current autocompletion state because that would follow the actual idea of enumerated attributes limited to only known values. Indeed, these kind of enumerated attributes doesn't return the content value but the value associated with the current state and in that case the 'state' is the autocompletion state. Practical speaking, autocomplete is mostly used in writing (authors want to force/disable autocomplete) and we can assume that a script reading this value is going to check if the element have autocompletion. Having input.autocomplete returning this state may prevent the authors to repeat the algorithm thus preventing errors and making further changes in specification easier (and transparent). By the way, why autocomplete IDL attributes have been introduced in the specifications? Thanks, -- Mounir
Re: [whatwg] HTML resource packages
> So if resource packages don't share caches, you need to either give up > on caching, [or] put a given file only in one resource package on your > whole site. The latter is not practical if pages use small, fairly > random subsets of your assets and it's not feasible to package them > all on every page view. Think avatars on a web forum I think this is a fair point. But I'd suggest we consider the following: * It might be confusing for resources from a resource package to show up on a page which doesn't "opt-in" to resource packages in general or to that specific resource package. * There's no easy way to opt out of this behavior. That is, if I explicitly *don't* want to load content cached from a resource package, I have to name that content differently. * The avatars-on-a-forum use case is less convincing the more I think about it. Certainly you'd want each page which displays many avatars to package up all the avatars into a single package. So you wouldn't benefit from the suggested caching changes on those pages. You might benefit on a user profile page which just displays one avatar. You might try and be clever and leave the avatar out of the profile page's resource package on the assumption that the UA already has that avatar in its cache. But then your page would load slower for users who visited the profile page without first getting the avatar from another resource package. Maybe you'd benefit from the suggested changes if you'd half-deployed resource packages on your site, so some pages had packages and others didn't. But I don't think that's a use case we should design for. In general, I think we need something like SPDY to really address the problem of duplicated downloads. I don't think resource packages can fix it with any caching policy. -Justin On Fri, Aug 6, 2010 at 2:17 PM, Aryeh Gregor wrote: > On Tue, Aug 3, 2010 at 8:31 PM, Justin Lebar wrote: >> We at Mozilla are hoping to ship HTML resource packages in Firefox 4, >> and we wanted to get the WhatWG's feedback on the feature. >> >> For the impatient, the spec is here: >> >> http://people.mozilla.org/~jlebar/respkg/ > > I have some concerns about caching behavior here, which I've mentioned > before. Consider a site that has a landing page that has lots of > first-time viewers. To accelerate that page view, you might want to > add a resource package containing all the assets on the page, to speed > up views in the cold cache case. Some of those assets will be reused > on other pages, and some will not. > > When the user navigates to another page, what's supposed to happen? > If you hadn't used resource packages at all, they would have a hot > cache, so they'd get all the shared assets on every subsequent page > view for free. But now they don't -- instead of the first view being > slow, it's the second view, when they leave the landing page. This > isn't a big improvement. > > So if resource packages don't share caches, you need to either give up > on caching, put a given file only in one resource package on your > whole site. The latter is not practical if pages use small, fairly > random subsets of your assets and it's not feasible to package them > all on every page view. Think avatars on a web forum: you might have > 20 different avatars displayed per page, from a pool of tens of > thousands or more. Do you have to decide between not using resource > packages and not getting any caching? > > You've said before that your goal in this requirement is > predictability -- if there's an inconsistency between different > resource packages or between a resource package and the real file, you > don't want users to get different results depending on what order they > visit the pages in. This is fair enough, but I'm worried that the > caching problems this approach causes will make it more of a hindrance > than a benefit for a wide class of use-cases. There's some possible > inconsistency anyway whenever caching is permitted at all, because if > the page provides incorrect caching headers, the UA might have an > out-of-date copy. Also, different browsers will be inconsistent too, > until all UAs in common use have implemented resource packages -- some > will use the packaged file and some the real file. Is the extra > inconsistency from letting the caches mix really too much to ask for > the cacheability benefits? I don't think so. >
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Sat, Aug 7, 2010 at 1:57 AM, Mike Wilcox wrote: > Regarding fullscreen elements: I appreciate the initiative, but I wonder if > it's necessary to allow fullscreen at the element level? It's not necessary, but it's a very useful convenience. It also allows the UA to perform transition effects that are impossible just at the author level. I think Simon is already pointing out potential gotchas. What exactly is the > difference between a fullscreen-element and a fullscreen-page that has an > element in absolutely position, top z-index, at 100% width and height? Nothing; see the proposed UA style sheet additions in the spec. > As a developer, after entering fullscreen I could possibly do a fancy > transition of the element to take up 100%. > You can't do it as well as the UA can, because a really good transition effect involves desktop-level effects that authors don't have access to. For example you might want part of the window to zoom out and cover the entire screen, semi-transparent over the desktop while zooming. I would disrecommend authors trying to create custom transition effects that depend on geometry; they probably won't work across browsers because they'll interfere with the UA's effects. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Sat, Aug 7, 2010 at 1:39 AM, Mike Wilcox wrote: > Kudos to Mozilla (and Robert?). This is awesome. It does appear that you > plan to allow fullscreen without the use of a user-trigggered event such as > a button-click like Flash does. The proposed spec allows that, but I think browsers are likely to prevent "drive-by fullscreen". First a small thing. The format of the CSS style: > :full-screen > :full-screen-root-with-target > I don't see why "fullscreen" should be hyphenated. Even the title of the > page uses it as one word. > I could go either way, but "full-screen" technically more correct. BTW you seem to be reading an old version of the spec. I don't understand the use of requestFullScreenWithKeys(). Why would I ever > use a more restrictive method? As the spec explains, by opting into more restrictions, you can get a lower bar to access fullscreen mode. > I assume the entire reason for security is for third party apps (video) and > advertisements (have I missed an actor?). > There's a set of problems there, but there's another set of problems where the user simply visits evil.com and that site tries to go fullscreen to launch some kind of spoofing attack. The first, simple use case I'm looking to solve is to block your ads from > using fullscreen. I don't see a way to do that in the spec. I recommend the > above options are properties of the document.body: > > This kind of thing would be better expressed with CSP. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Re: [whatwg] input type=upload (not just files) proposal
On Fri, Aug 6, 2010 at 3:10 PM, Ian Hickson wrote: > I think it might make sense to expose file upload progress on a > to a same-origin server. It would be interesting to see how the equivalent > feature in XMLHttpRequest is received before we add this, though. > > I've made a note of it. I also want to chip in that this would be really really awesome. It would be much less pressing if browsers could just be persuaded to add prominent native UI for this, of course . . .
Re: [whatwg] HTML resource packages
On Tue, Aug 3, 2010 at 8:31 PM, Justin Lebar wrote: > We at Mozilla are hoping to ship HTML resource packages in Firefox 4, > and we wanted to get the WhatWG's feedback on the feature. > > For the impatient, the spec is here: > > http://people.mozilla.org/~jlebar/respkg/ I have some concerns about caching behavior here, which I've mentioned before. Consider a site that has a landing page that has lots of first-time viewers. To accelerate that page view, you might want to add a resource package containing all the assets on the page, to speed up views in the cold cache case. Some of those assets will be reused on other pages, and some will not. When the user navigates to another page, what's supposed to happen? If you hadn't used resource packages at all, they would have a hot cache, so they'd get all the shared assets on every subsequent page view for free. But now they don't -- instead of the first view being slow, it's the second view, when they leave the landing page. This isn't a big improvement. So if resource packages don't share caches, you need to either give up on caching, put a given file only in one resource package on your whole site. The latter is not practical if pages use small, fairly random subsets of your assets and it's not feasible to package them all on every page view. Think avatars on a web forum: you might have 20 different avatars displayed per page, from a pool of tens of thousands or more. Do you have to decide between not using resource packages and not getting any caching? You've said before that your goal in this requirement is predictability -- if there's an inconsistency between different resource packages or between a resource package and the real file, you don't want users to get different results depending on what order they visit the pages in. This is fair enough, but I'm worried that the caching problems this approach causes will make it more of a hindrance than a benefit for a wide class of use-cases. There's some possible inconsistency anyway whenever caching is permitted at all, because if the page provides incorrect caching headers, the UA might have an out-of-date copy. Also, different browsers will be inconsistent too, until all UAs in common use have implemented resource packages -- some will use the packaged file and some the real file. Is the extra inconsistency from letting the caches mix really too much to ask for the cacheability benefits? I don't think so.
Re: [whatwg] [br] element should not be a line break
On Fri, Aug 6, 2010 at 4:29 PM, Aryeh Gregor wrote: > > On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields wrote: > > Why not just list along with the other obsolete elements instead of > > trying to rebrand it semantically? > > What markup do you propose for addresses and poems, and in what > practical sense would this markup be superior to using ? The HTML5 spec says of : "The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements." sounds ideal for both examples to me (in conjunction w/ the element in the second example. It preserves the line breaks w/o adding any overhead markup to the mix. -- - Bryce Fields www.royalrodent.com "Do or do not. There is no try." -- Yoda
Re: [whatwg] IDL attribute reflecting enumerated attributes not limited to only know values
On Fri, Aug 6, 2010 at 3:01 PM, Ian Hickson wrote: > I'm happy to make more of them limited, especially new attributes or ones > that were already that way, but I'd rather not change the default as that > can have unexpected effects (e.g. some of the attributes are definitely > not so limited, and I don't recall which that might be). See discussion last Tuesday in #whatwg: http://krijnhoetmer.nl/irc-logs/whatwg/20100803#l-875 Some notable lines: # [20:56] I think we should change all enumerable attributes to be limited like that # [20:57] it makes sense to ignore on setting to unknown value # [20:57] it is what does as well # [20:57] and gives the ability to do feature testing # [20:58] I guess we should just implement it so the spec can remove the whole concept of "limited to known values" and make it part of the enumerable attributes definition # [20:59] actually, some time ago i proposed (in a mail) to move the default behavior to be limited to only known values # [20:59] and if, needed, case by case, don't limit the attribute # [21:02] AryehGregor, I suspect no content relies on this, though I'm not a 100% sure of course # [21:02] AryehGregor, the most problematic are probably knew enumerated attributes on existing elements # [21:02] s/knew/new/ # [21:03] I just went through the spec; there are not too many either The enumerated attributes in the spec right now that are not limited to only known values are, by my count: * audio.preload, video.preload (note that at least WebKit appears to treat these as limited to known values already) * command.type * form.autocomplete, input.autocomplete * marquee.direction * marquee.trueSpeed * meta.httpEquiv * textarea.wrap * th.scope * track.kind It doesn't say either way for device.type (there's no line about it having to reflect anything). The contenteditable, draggable, and spellcheck attributes have magic behavior of their own. What do other implementers think about this? Is the compat risk from changing all of these to be limited to only known values worth it? It would make the platform more consistent -- there's no rhyme or reason right now to which ones are limited to only known values and which aren't. Being limited to known values seems more convenient than not, so if we can standardize on one, that's the better one.
Re: [whatwg] and links with @rel=embed
On Fri, Aug 6, 2010 at 1:12 PM, Ashley Sheridan wrote: > On Fri, 2010-08-06 at 12:43 -0700, Tab Atkins Jr. wrote: >> Do browsers supply a file extension for un-extensioned files based on >> the mimetype? I didn't think they did. A file without an extension >> confuses most people. > > It would confused Windows users mostly, who have no way to detect a file type > that has no extension. Linux and Mac users will generally be in a better > position. That would be "most users". ^_^ >>> "Virtually always" seems like an overstatement based on how often I >>> see people extract sound tracks from Youtube videos (and how I often I >>> see people don't in part due to them only having a dumb one-off >>> Flash-based video player). Or try to sequence playing of arbitrary >>> songs from Youtube with multiple browser windows + manual play/pausing >>> hackery. Or other things that would be trivial with their usual media >>> player. >> >> You're running with a very non-representative crowd if those are the >> sorts of things your friends do. > > I'm not sure you can say that's non-representative without supplying some > sort of backup evidence. The very fact that people do this sort of thing > should be enough for a use-case. As it is though, despite having issues with > Flash video on Linux (my platform of choice) I would prefer it as a backup > in-case I didn't have the right codecs installed. This will likely apply more > to Windows users though, as a default Windows install (I'm basing this on XP, > which is still extremely popular and is the latest version of Windows with > which I'm very familiar) doesn't come with a huge range of codecs. Oh, I don't doubt the use-case. That case is served quite well right now, as all browsers expose a "Save As..." option in the video context menu. I'm disputing that it's the *common* case, such that it needs to be explicitly catered to. >>> And as SVG is not universally supported, what if I want to offer some >>> logos/icons/images as both (gzipped) SVG and PNG? >> >> SVG is in the process of being universally supported right now. Once >> IE9 is out, every modern browser will support it. > > There's still a huge amount of XP users about (going by various statistics > sites) which won't ever support IE9. Also, XP SP3 is supported until at least > 2014, so there's likely a whole slew of Windows machines that will never see > IE9. I think it's fairly safe to say that the majority of these will be > business machines, and many corporate environments won't allow extraneous > software, such as an alternative browser, to be installed. As such, it's back > to Flash again as a default fallback, as that is the only thing that can be > almost guaranteed in that sort of environment. Like I said just after this section of my email, you'll be able to serve SVG long before you'll be able to serve a generic media container with fallback ability. If a user is stuck with an outdated browser that won't show SVG, *they're stuck with an outdated browser*. Even if we introduced something that will automatically fallback from SVG to PNG, IE6-8 will still fail to show anything. ~TJ
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields wrote: > Why not just list along with the other obsolete elements instead of > trying to rebrand it semantically? What markup do you propose for addresses and poems, and in what practical sense would this markup be superior to using ?
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 1:48 PM, Ryosuke Niwa wrote: > That's totally incorrect in HTML5 as Thomas has pointed out. As I pointed out, it's only theoretically incorrect. still means "something that's conventionally boldface", and still means "something that's conventionally italic". > Let me ask you > a question. What do you suppose non-visual user agent should do when they > encounter br? Simply ignore them because it only signifies a line break? > Or read out that there's a line break? Neither seems user friendly to me. > If anything, a momentary pause will be appropriate because what's what we > usually do when reading a book and a line break appears. This clearly isn't > *line break*. No, but it's a stand-in for a class of semantics that can only fairly be summarized as "the places where you would always use a line break in print". There is no single behavior that screen readers could use to correctly present , but the same is true for any number of other cases. How to pronounce the word "minute" depends on context too, because the sequence of letters M-I-N-U-T-E can signify multiple concepts that happen to be represented the same way textually, but vary when spoken. There is no realistic way to avoid this kind of thing. Even if you eliminate it on the markup level, it remains on the level of text, so you haven't actually made the problem go away. Instead, we rely on the fact that a listener can usually extract the meaning pretty well even if some of the fine distinctions are lost, and focus accessibility efforts on avoiding only drastic misrepresentations (like missing content images). This discussion would not even be occurring if not for incidental choices in the underlying technology. If HTML respected Unicode line breaks, no one would propose that Unicode line breaks must be axed in favor of a semantic solution. Insisting that every single HTML element must be fully semantic and media-independent, while ignoring the fact that web pages are written in text and that is *intrinsically* not media-independent, does not make any sense.
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 5:24 AM, Thomas Koetter wrote: > That's not correct. Then give a counterexample. > Actually, I shouldn't have used the term "definition list" as such a list > type does not exist in HTML5. The meaning of the dl element has been changed > to that of an association list (name/value pairs). So, it can and should be > used for addresses. I maintain that it is the most semantically rich HTML5 > element for addresses. It cannot be used if you don't want to include the words like "Street:", which are typically omitted, unless you add the s with display: none, which is unreasonable. > According to the spec it is perfectly acceptable to leave out all dt elements: > "If a dl element contains only dd elements, then it consists of one group > with values but no names." That says what the meaning is of a dl element with no dt elements. It doesn't say such a group is permitted. The normative authoring requirements are in the first two sentences of the element's description: "The dl element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements)." Every group must have a element. > Which elements currently let me logically break up a paragraph? I can't think > of any. There are only a handful of empty elements (like br, wbr, hr, img, > input, param, embed). Except br none of them would be appropriate in such a > case. No elements do. Characters do, though. Every period, comma, semicolon, colon, and dash is a minor logical break in the paragraph, but it would be incorrect to use for any of those. > I would disagree here because I don't consider punctuation to be > presentational. I'd say it's content because leaving punctuation out can > change the meaning. So can omitting line breaks. The address 123 Imaginary Place New York, NY 12345 is not the same as 123 Imaginary Place New York, NY 12345 Indeed, the spec explicitly forbids using where the line break is presentational: "br elements must be used only for line breaks that are actually part of the content, as in poems or addresses."
Re: [whatwg] Non-blocking SVG Canvas?
On 8/5/10 9:14 PM, Kevin Ar18 wrote:
First off, where would be an appropriate area to continue this conversation?
Here is probably fine, unless you want one of www-st...@w3.org or
www-...@w3.org.
I'm guessing the discussion is becoming less relevant to the HTML5 spec...
But this isn't an HTML5 spec list... It's a whatwg spec list (which
includes a lot more than HTML5).
* Why do browsers do this? Is there somewhere in the specs that says empty (the
transparent areas of) svg tags embedded inside another svg tag should "act like they
do not exist"?
One could interpret section 16.4 of the SVG 1.1 specification as saying
this, maybe. I'm not sure whether any UAs actually implement that (in
particular dropping on the floor events with no graphic element under
them in SVG documents). Webkit and Opera certainly trigger the event
handler for a click anywhere in the viewport given this SVG document:
http://www.w3.org/2000/svg"; onclick="alert('clicked')"/>
-Boris
Re: [whatwg] and links with @rel=embed
On Fri, 2010-08-06 at 12:43 -0700, Tab Atkins Jr. wrote: > On Thu, Aug 5, 2010 at 7:43 PM, Bjartur Thorlacius > wrote: > > On 8/5/10, Tab Atkins Jr. wrote: > >> I'll note, though, that that isn't a very useful pattern for users in > >> the first place. Most users won't have any idea what to do with a > >> video file, especially if it doesn't come with an identifying > >> extension. > >> > > I don't understand the comment about identifying extension. What's wrong > > with > > IANA/MIME media types? Format metadata is often represented as a name/icon > > combo anyway. > > Servers often don't serve their videos with the correct mimetype. IIS I believe is notorious for not sending out the right mime type, and it's default list of recognised types is quite limited compared to Apache. Thankfully it's not the most popular of web servers out there. > > Do browsers supply a file extension for un-extensioned files based on > the mimetype? I didn't think they did. A file without an extension > confuses most people. It would confused Windows users mostly, who have no way to detect a file type that has no extension. Linux and Mac users will generally be in a better position. > > > > And having the video prevents them from opening it in their media player > > how? > > Video playback consist mostly of a mouse click and some watching. > > Codecs are completely irrelevant. > > Huh? Codecs are certainly relevant *if you don't have the correct > codec installed to decode the video*. For example, I don't think > Windows Media Player by default includes the necessary codec to decode > Ogg Theora, and I know it doesn't to decode WebM. > > > >> Doing a Flash or similar fallback that still plays the video is > >> virtually always the best choice for the user. > >> > > "Virtually always" seems like an overstatement based on how often I > > see people extract sound tracks from Youtube videos (and how I often I > > see people don't in part due to them only having a dumb one-off > > Flash-based video player). Or try to sequence playing of arbitrary > > songs from Youtube with multiple browser windows + manual play/pausing > > hackery. Or other things that would be trivial with their usual media > > player. > > You're running with a very non-representative crowd if those are the > sorts of things your friends do. I'm not sure you can say that's non-representative without supplying some sort of backup evidence. The very fact that people do this sort of thing should be enough for a use-case. As it is though, despite having issues with Flash video on Linux (my platform of choice) I would prefer it as a backup in-case I didn't have the right codecs installed. This will likely apply more to Windows users though, as a default Windows install (I'm basing this on XP, which is still extremely popular and is the latest version of Windows with which I'm very familiar) doesn't come with a huge range of codecs. > > Ordinary people watch videos. That's that. Ordinary people do all sorts of things. I'm seeing a lot of non-techy friends mashing existing clips from services like YouTube. If they're doing this, they at least know enough about codecs, but the option to be able to actually do something more than watch the video is important. > > > > What's wrong with solving the problem once for all? > > Every solution costs something. If solving it "once and for all" is > more expensive than the benefit it'll bring, it's not worth doing. > That also presumes that you have a good, correct solution in the first > place. > > > > And as SVG is not universally supported, what if I want to offer some > > logos/icons/images as both (gzipped) SVG and PNG? > > SVG is in the process of being universally supported right now. Once > IE9 is out, every modern browser will support it. There's still a huge amount of XP users about (going by various statistics sites) which won't ever support IE9. Also, XP SP3 is supported until at least 2014, so there's likely a whole slew of Windows machines that will never see IE9. I think it's fairly safe to say that the majority of these will be business machines, and many corporate environments won't allow extraneous software, such as an alternative browser, to be installed. As such, it's back to Flash again as a default fallback, as that is the only thing that can be almost guaranteed in that sort of environment. > > It's quite certain that you'll be able to use SVG before you'll be > able to use a generic media container holding both SVG and PNG for > fallback. It's not usually worthwhile to try and solve things that > will solve themselves, given a little more time. > > ~TJ Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 7:03 PM, Jeremy Keith wrote: > This is no longer true. The semantics of and have been changed in > HTML5, specifically to separate the presentation from the meaning. > Specifically, any reference to screen- or page-specific styling like "bold" > and "italic" have been removed (allowing the elements to still have meaning > in a medium such as audio). It's kind of a fake, though, since the definition includes "spans of text whose typical typographic presentation is boldened" and "other prose whose typical typographic presentation is italicized". With those semantics, there's no sensible way to render them in any medium except bold and italics. In speech, you could never present them properly based on those semantics -- you'd probably just have to ignore them. For example, even if you wanted to audibly offset italicized thoughts (which you probably don't), you can't distinguish thoughts from ship names. The presentation-independence is hollow: the semantics are such that it is correct to use / for exactly those things that are conventionally bolded or italicized.
Re: [whatwg] input type=upload (not just files) proposal
On Fri, Aug 6, 2010 at 12:10 PM, Ian Hickson wrote: > I think it might make sense to expose file upload progress on a > to a same-origin server. It would be interesting to see how the equivalent > feature in XMLHttpRequest is received before we add this, though. > > I've made a note of it. Just as a note, I would murder people for this ability. (The XHR ability is great as well, but having it even simpler is always better.) ~TJ
Re: [whatwg] and links with @rel=embed
On Thu, Aug 5, 2010 at 7:43 PM, Bjartur Thorlacius wrote: > On 8/5/10, Tab Atkins Jr. wrote: >> I'll note, though, that that isn't a very useful pattern for users in >> the first place. Most users won't have any idea what to do with a >> video file, especially if it doesn't come with an identifying >> extension. >> > I don't understand the comment about identifying extension. What's wrong with > IANA/MIME media types? Format metadata is often represented as a name/icon > combo anyway. Servers often don't serve their videos with the correct mimetype. Do browsers supply a file extension for un-extensioned files based on the mimetype? I didn't think they did. A file without an extension confuses most people. > And having the video prevents them from opening it in their media player how? > Video playback consist mostly of a mouse click and some watching. > Codecs are completely irrelevant. Huh? Codecs are certainly relevant *if you don't have the correct codec installed to decode the video*. For example, I don't think Windows Media Player by default includes the necessary codec to decode Ogg Theora, and I know it doesn't to decode WebM. >> Doing a Flash or similar fallback that still plays the video is >> virtually always the best choice for the user. >> > "Virtually always" seems like an overstatement based on how often I > see people extract sound tracks from Youtube videos (and how I often I > see people don't in part due to them only having a dumb one-off > Flash-based video player). Or try to sequence playing of arbitrary > songs from Youtube with multiple browser windows + manual play/pausing > hackery. Or other things that would be trivial with their usual media > player. You're running with a very non-representative crowd if those are the sorts of things your friends do. Ordinary people watch videos. That's that. > What's wrong with solving the problem once for all? Every solution costs something. If solving it "once and for all" is more expensive than the benefit it'll bring, it's not worth doing. That also presumes that you have a good, correct solution in the first place. > And as SVG is not universally supported, what if I want to offer some > logos/icons/images as both (gzipped) SVG and PNG? SVG is in the process of being universally supported right now. Once IE9 is out, every modern browser will support it. It's quite certain that you'll be able to use SVG before you'll be able to use a generic media container holding both SVG and PNG for fallback. It's not usually worthwhile to try and solve things that will solve themselves, given a little more time. ~TJ
Re: [whatwg] input type=ink proposal
On Tue, 8 Jun 2010, Charles Pritchard wrote: > > As part of a web form, a user signs their digital signature to confirm > acceptance of terms. > > While filling out an online profile, a user submits a simple doodle as > their avatar. > > To quickly log into an online system, a user scribbles a password, which > their server tests for fidelity to their prior scribbled input. Are there examples of sites working around the lack of this feature on the Web today, e.g. using Flash or some such? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=upload (not just files) proposal
On Tue, 8 Jun 2010, Eitan Adler wrote: > > A lot of websites let you upload either from a file on your hard drive > or from a link on the web. Most of the time this is done by having two > different inputs: One for a file and the other for a URL. > > If there were some type of input like "upload' which will allow for > any complete input. > Something like > file:///home/eitan/file_to_upload.pdf > or > http://example.com/file.pdf > or > ftp://user:passw...@example.com/file.pdf > > It would then be the server's job to fetch the file unless the user > passed it a file:// scheme it which case the file would be provided by > the UI. As far as I can tell nothing stops a browser from doing this today with . Indeed, on Windows it's probably already supported since the default Open File dialog supports URLs. On Wed, 9 Jun 2010, Rob Evans wrote: > > I think an interesting addition to the input type=upload would be a > script-accessible progress value. Either as a percentage, or probably > more useful two values, one being the size of the upload and the other > being current bytes sent. I think it might make sense to expose file upload progress on a to a same-origin server. It would be interesting to see how the equivalent feature in XMLHttpRequest is received before we add this, though. I've made a note of it. > Also whilst we're on the subject, how about allowing multiple files to > be selected from a single input element? This is in the spec now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] IDL attribute reflecting enumerated attributes not limited to only know values
On Tue, 8 Jun 2010, Mounir Lamouri wrote: > > An example where this behavior seems buggy: > - input.type and button.type: every browser makes it return "text" if > @type isn't set to a known value. If we follow the specifications, .type > should return the current value of @type. Fixed. > Examples where having another behavior would help: > - method, formmethod, enctype and formenctype have a list of > keywords/states with a default missing value. It would be great to have > the IDL attribute returning the current state instead of the content. > So, scripts wouldn't have to look at the content, checking for values > they know and falling-back to the default value to know the current state. Done. This appears to be a compatibility fix for enctype and a compatibility change for method, based on Chrome's current behaviour. > - input.autocomplete: at the moment, it is returning the content but it > could return the resulting autocompletion state which is maybe a bit > more than just being limited to only known values but still in the same > spirit. I haven't changed this; what's the use case for knowing the actual state? > Maybe, instead of having some attributes "limited to only known values" > we could have some attributes "not limited to only known values", thus > inverting the default reflecting behavior for enumerated attriutes ? I'm happy to make more of them limited, especially new attributes or ones that were already that way, but I'd rather not change the default as that can have unexpected effects (e.g. some of the attributes are definitely not so limited, and I don't recall which that might be). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML resource packages
On Fri, Aug 6, 2010 at 12:46 AM, Christoph Päper wrote: > Justin Lebar: >> Christoph Päper wrote: >>> >>> Why do you want to put this on the HTML level (exclusively), not the HTTP >>> level? >> >> If you reference an image from a CSS file and include that CSS file in an >> HTML file which uses resource packages, the image can be loaded from the >> resource package. > > Yeah, it’s still wrong. > > Resource packages in HTML seem okay for the image gallery use case (and then > could be done with ‘link’), but they’re commonly inappropriate for anything > referenced from ‘link’, ‘script’ and ‘style’ elements. Your remark on loading > order just proves this point: you want resource packages referenced before > ‘head’. You should move one step further than the root element, i.e. to the > transport layer. This doesn't seem to make sense. If you want resource packages referenced before , then the nearest appropriate location is still . Moving it up to the transport layer isn't *wrong*, but it's not *necessary* in this case. ~TJ
Re: [whatwg] HTML resource packages
On Fri, Aug 6, 2010 at 12:46 AM, Christoph Päper wrote: > Justin Lebar: >> Christoph Päper wrote: >>> >>> Why do you want to put this on the HTML level (exclusively), not the HTTP >>> level? >> >> If you reference an image from a CSS file and include that CSS file in an >> HTML file which uses resource packages, the image can be loaded from the >> resource package. > > Yeah, it’s still wrong. > > Resource packages in HTML seem okay for the image gallery use case (and then > could be done with ‘link’), but they’re commonly inappropriate for anything > referenced from ‘link’, ‘script’ and ‘style’ elements. Your remark on loading > order just proves this point: you want resource packages referenced before > ‘head’. You should move one step further than the root element, i.e. to the > transport layer. We want resource packages to work for people who don't have the ability to set custom headers for their pages or who don't even know what an HTTP header is. I agree that it's a hack, but I don't understand how putting the packages information in the element makes it inappropriate to load from a resource package resources referenced in link, script, and style elements. Is the issue just that the HTML file's |packages| attribute affects what we load when we see @import url() in a separate CSS file? This seems like a feature, not a bug, to me. SPDY will do this the Right Way, if we're patient. -Justin
Re: [whatwg] Discussing WebSRT and alternatives/improvements
Snipping liberally... On Thu, 05 Aug 2010 17:01:47 +0200, Silvia Pfeiffer wrote: CONSIDERING EXISTING FORMATS Note that the subtitling community has traditionally been using the Subrip (srt) or SubViewer (sub) formats as a simple format and SubStation alpha (ssa/ass) as the comprehensive format. Aegisub, the successor of SubStation Alpha, is still the most popular subtitling software and ASS is the currently dominant format. However, even this community is right now developing a new format called AS6. This shows that the subtitling community also hasn't really converged on a "best" format yet. Maybe it's just me, but I've very rarely seen ASS in the wild. In fact, almost all fansubbed videos I've seen were hardsubbed (subtitles encoded as part of the video), presumably because the subbers thought their choice of font and colors was really important. Perhaps they were still using ASS or similar to author the subtitles, I don't know. (In my own limited fansubbing efforts, SRT was quite sufficient.) A BRIEF OVERVIEW OF WMML I developed WMML as a xml-based caption format that will not have the problems that have been pointed out for DFXP/TTML, namely: there are no namespaces, it doesn't use XSL-FO but instead fully reuses CSS, and it supports innerHTML markup in the cues instead of inventing its own markup. Check out the examples at https://wiki.mozilla.org/Accessibility/Video_Text_Format . WMML's root element contains some attributes that are important for specifying how to use the resource: * a @lang attribute which specifies what language the resource is written for * a @kind attribute which specifies the intended use of the resource, e.g. caption, subtitle, chapter, description * a @profile attribute which specifies the format used in the cues and thus the parser that should be chosen, including "plainText", "minimalMarkup", "innerHTML", "JSON", "any" (other formats can be developed) If @profile should have any influence on the parser it sounds like this isn't actually XML at all. In particular, the "HTML" would have to be well-formed XML, but would still end up in the null namespace. I guess simply cloning the child nodes of and changing their namespace to before inserting them into an iframe-like document might work, but would be quite odd, I think you'll agree. An XML parser can't do anything special with JSON either, so I guess there's a post-processing step if an XML parser is going to be used? WMML completely reuses the HTML element. This has the following advantages: * there is a means to associate metadata in the form of name-value pairs with the time-synchronized text resource. There is a particular need to be able to manage at least the following metadata for time-synchronized text resources: ** the association with the media resource and its metadata, such as title, actors, url, duration ** the author, authoring date, copyright, ownership, license and usage rights for the time-synchronized text resource * there is a means to include in-line styles and a means to include a link to an external style sheet * there is a possibility to provide script that just affects the time-synchronized text resource I agree that some metadata would be useful, more on that below. I'm not sure why we would want to run scripts inside the text document, though, when that can be accomplished by using the TimedTrack API from the containing page. The elements have a start and end time attribute and contain innerHTML, thus there is already parsing code available in Web browsers to deal with this content. Any Web content can be introduced into a and the Web browsers will already be able to render it. Yes, but if the HTML parser can't be used for all of WMML, it makes the parser quite odd, being neither XML or HTML. I think that realistically the best way to make an XML-like format is to simply use XML. COMPARING WebSRT and WMML Examples that I experimented with are at https://wiki.mozilla.org/Accessibility/Video_Text_Format_Comparison . There are a few things I like about WebSRT. 1. First and foremost I believe that the ability to put different types of content into a cue is really powerful. It turns WebSRT into a platform for delivering time-synchronized text rather than just markup for a particular application of time-synchronized text. It makes it future-proof to allow absolutely anything in cues. 2. There is a natural mapping of WebSRT into in-band text tracks. Each cue naturally maps into a encoding page (just like a WMML cue does, too). But in WebSRT, because the setup information is not brought in a hierarchical element surrounding all cues, it is easier to just chuck anything that comes before the first cue into an encoding header page. For WMML, this problem can be solved, but it is less natural. I really like the idea of letting everything before the first timestamp in WebSRT be interprete
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Aug 5, 2010, at 9:24 PM, Robert O'Callahan wrote:
>
> It's probably worth having such an event, but there will be times when
> neither fullscreendenied or fullscreenchanged are fired. I hope authors don't
> write apps that break in such cases.
We definitely need some sort of event to indicate if fullscreen was successful
or not – not so that our apps don't break, but so we can notify the user of
failed functionality. Even a status property is insufficient as it will force
us to use a setInterval which seems hacky. And preferably, it would be good to
know the reason for the denial:
onFullscreenDenied = function(status){
if(status=="blocked by browser"){
alert("You need to change your browser's settings to use
fullscreen mode.");
}else if(status=="blocked by page"){
disableMyFullScreenButton();
alert("Sorry, fullscreen is not available.");
}
}
Regarding fullscreen elements: I appreciate the initiative, but I wonder if
it's necessary to allow fullscreen at the element level? I think Simon is
already pointing out potential gotchas. What exactly is the difference between
a fullscreen-element and a fullscreen-page that has an element in absolutely
position, top z-index, at 100% width and height? As a developer, after entering
fullscreen I could possibly do a fancy transition of the element to take up
100%. I have to assume this is what the UA would be doing in the background
anyway in order to keep the proper x/y coordinates.
Mike Wilcox
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
Kudos to Mozilla (and Robert?). This is awesome. It does appear that you plan
to allow fullscreen without the use of a user-trigggered event such as a
button-click like Flash does. Not only would I like to launch my app in
fullscreen to play a game, I may want to allow my advertisers to launch
fullscreen videos for a premium fee. I think this is a good thing. It's
important to keep restriction versatile so that both the user and developer are
in control. As opposed to too much security completely killing the feature and
force developers to continue to rely upon Flash.
First a small thing. The format of the CSS style:
:full-screen
:full-screen-root-with-target
I don't see why "fullscreen" should be hyphenated. Even the title of the page
uses it as one word.
I don't understand the use of requestFullScreenWithKeys(). Why would I ever use
a more restrictive method? How about just fullscreen() - and it toggles? And
security is handled through element attributes?
I assume the entire reason for security is for third party apps (video) and
advertisements (have I missed an actor?). It seems to me that I would want to
prevent a third party from calling fullscreen. The spec makes it look like its
up to the developer on whether to use the security or not. Did I read it wrong?
The spec focuses a lot on iframes. It's fine to restrict functionality in an
iframe, but a majority of third party apps and advertisements don't happen in
an iframe, they are written to the page, often with document.write – and they
often write their own iframe. The iframe restriction will work for scenarios
such as an HTML5 Video embed, but not for ads.
Here are some suggested constants. The actual spelling or exact usage is not
relevant, I'm addressing functionality (I agree with Anne on constants in JS).
I'm looking at these suggestions mostly from the POV of a web developer, not a
user nor user agent.
The first, simple use case I'm looking to solve is to block your ads from using
fullscreen. I don't see a way to do that in the spec. I recommend the above
options are properties of the document.body:
Note however, that I recommend that allowFullscreen="block" be the default, so
ads can't start launching fullscreen in existing, unmaintained pages.
The second simple scenario is to use fullscreen but you don't need to worry
about ads:
The third scenario gets more tricky, and is why I am suggesting using the
properties as node attributes. Think about the NY Times wanting to allow
fullscreen to read the article but block ads (or certain ads) from fullscreen:
The suggestion is that fullscreen permissions are on the element level and are
inherited. Further, they should be only writable in HTML markup, and read-only
in JavaScript so permissions cannot be dynamically changed.
A potential problem is a rouge third party script scanning the page to find the
article element allows fullscreen; and it writes content to it and launches it.
The solution could be that allowFullscreen is NOT readable by JavaScript – it
can only discover permissions by the attempt to go fullscreen.
A modification to this would be a write-once apiKey that is private:
document.setFullscreenApiKey("mysecret"); // set only once, subsequent
calls ignored, cannot be read
onClick = function(){
requestFullScreen("mysecret");
}
I think this idea is clever, but I may be over thinking it.
allowFullscreen="userIntiated,mouseOnly" is probably all that is needed in this
case (and perhaps most cases).
Of course, nothing is 100% secure, and since this is the list that said DRM is
impossible, I'm really advocating that we don't try for 100% safety and cripple
the feature.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Aug 5, 2010, at 5:17 PM, Simon Fraser wrote:
> This is feedback on the Mozilla FullScreen API proposal here:
>
Re: [whatwg] Race condition in media load algorithm
On 8/6/10 4:04 AM, Philip Jägenstedt wrote: See, this concept of "a script" is a funny one, given that scripts are reentrant, and that multiple different scripts can all be running at the same time, possibly with event loops nested in between on the conceptual callstack Well, what we really look at is an execution thread. When a script triggers a synchronous event handler or is otherwise suspended while waiting for another thread to finish, we will wait for the "outermost" suspended thread to finish executing. So, yeah, it's not completely trivial :) That really doesn't sound like it maps well to the proposed HTML5 spec, for what it's worth... Of course it sounds like you're suggesting the spec should be changed (without actually describing your changes in speccable non-implementation-specific terms). Who said anything about infinite loops? It's one way of a script not finishing. OK, sure. But if a script s busy-looping, I think we all agree that's not considered a time when synchronous sections can be run. If a script is showing a modal dialog, not loading a video in the background seems fine. Why? It doesn't seem fine to me at all. My point is that no one uses modal dialogues That's not the case, sadly. Gecko had to implement them for compat reasons, for example. In any case, modal dialogs are just one place where the issue arises. Other situations per current spec that may or may not correspond to threads being suspended in your model: 1) Spinning the event loop while the parser is blocked on a that's waiting on stylesheets to load. 2) Spinning the event loop at parse end waiting for deferred scripts.that seems to be it; the remaining cases are pauses in the spec. That said, I still think the behavior of pause (which you're proposing for showModalDialog as well, I think) makes no sense; I'd much rather have the showModalDialog behavior for things like sync XHR, alerts, etc.It's possible that it can't. It would depend on the exact steps that run in the synchronous section, but since synchronous sections can't trigger script it might not be detectable at all.The most important things is that the following always alert 3 (NETWORK_NO_SOURCE):