[whatwg] Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: Allow Select SVG Elements In head)
Bueller...? Bueller...? This request is almost 5 years old now, but it is even more relevant today, now that web developers are increasingly embracing SVG for purposes of responsive design and accommodating HiDPI displays. Putting SVG defs and other metadata-related elements in HTML's head seems like an obvious choice from a semantic standpoint. But it is currently illegal in the HTML spec because SVG does not distinguish between embedded and metadata content models for its elements, which Hixie has requested so that the HTML spec can simply point to the SVG spec's definitions. (Please see quoted text.) Again, is this something the SVG WG is willing to do? Thank you, Hugh On Thu, Dec 22, 2011 at 7:28 AM, Hugh Guiney hugh.gui...@gmail.com wrote: Cameron McCormack forwarded this proposal to public-svg-wg a year ago (thanks, Cameron!) but no one commented on it, so I'm reposting it here. Is this something the SVG WG is willing to do? Thanks! -Hugh -- Forwarded message -- From: Ian Hickson i...@hixie.ch Date: Mon, Dec 6, 2010 at 9:35 PM Subject: Re: [whatwg] Allow Select SVG Elements In head To: Hugh Guiney hugh.gui...@gmail.com Cc: whatwg wha...@whatwg.org On Fri, 27 Aug 2010, Hugh Guiney wrote: I'm authoring an XHTML host document with namespaced inline SVG and XLink. I have vector images that recur throughout the site. I'd like to implement SVG's defs and use to reduce the file size of the document and keep style separate from content, as with CSS. If I put an SVG tree with defs anywhere in the XHTML document, other trees with use xlink:href will correctly reference it, as tested in the latest public release Gecko, Webkit, and Opera. So the question becomes, where do I put it? The most obvious answer seems to be head, since, like CSS definitions, this is metadata being defined for use elsewhere in the document. The only problem is, Validator.nu doesn't like it: Error: SVG element svg not allowed as child of XHTML element head in this context. (Suppressing further errors from this subtree.) Same error when ditching the root svg and including only defs, the result of which still works in all but Opera. This error can be avoided if the defs tree is put in the XHTML body, but then there is blank space the size of the defined shapes at the top of the document in all 3 engines. A workaround is to give svg a @width and @height both of 0. But leaving the definitions in the body when they technically don't represent contextual content strikes me as non-semantic. My proposition would be to simply spec a subset of SVG consisting only of metadata elements as valid in HTML's head context. This could be just defs—I'm unsure if there are any other elements that fit this definition since I am relatively new to SVG; but in either case it'd aid semantics and is already supported in today's SVG-capable browsers. This is an interesting idea. I would recommend approaching the SVG working group and suggesting that they define the content model of svg and other SVG elements such that there's two ways to use it: one where svg is considered embedded content, and one where it's considered metadata content, with appropriate restrictions on the latter. With such a set of definitions in place, the HTML spec's model would just work (it already refers to the content model of head as just metadata content, for instance). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 8:21 PM, Eitan Adler li...@eitanadler.com wrote: Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. What if both exist but are different elements? Favor the first or most ancestral occurrence.
Re: [whatwg] A plea to Hixie to adopt main
As a developer I'm in favor of this. Just take a look at the how popular the question of How do I enable Reader mode is on SO[1], and how complex and mysterious the actual algorithm appears to be[2], and it's evident how authors and implementors alike could benefit from a dedicated element. Although, there's the question of how similar in definition it'd be to article. Is it merely a more specific version of a self-contained composition [...] that is, in principle, independently distributable? Or is it a more specific div; a semantic wrapper element? If it's the former, this could just as well be an empty attribute, as article main. Not too different from ARIA, which maybe makes it a little redundant, but it's less to type in CSS (article[main] vs article[role=main]), and also achieves landmark parity without breaking legacy HTML parsers, frameworks, etc. which only expect article. If it's the latter, it probably makes more sense for it to be an element, where it wouldn't say whether the content was self-contained or not; just that its contents are considered the primary focus of the page, except anything that would otherwise be excluded in the document outline. [1]: http://stackoverflow.com/questions/2997918/how-to-enable-ios-5-safari-reader-on-my-website [2]: http://mathiasbynens.be/notes/safari-reader
Re: [whatwg] Submitting contentEditable Content In A Form
On Wed, Oct 17, 2012 at 7:23 PM, Ian Hickson i...@hixie.ch wrote:
I haven't added this, because contenteditable= is only truly useful with
scripting enabled, and it's basically one line of script to support
shunting the current value into a hidden input.
For me, it's also useful even just as a way for blog contributors to
edit the content of posts in-context (i.e., with styling applied, as
it will appear on the final page, rather than blindly inside a
textarea). Obviously it's going to be more versatile with scripting
enabled, but that's true across the board, and contenteditable doesn't
lose all value merely by virtue of the user not being able to add
specific formatting: additional formatting could occur server-side
(think Markdown expansion); a lot of content on the Web consists
primarily or even exclusively of paragraphs; an editor could make
purely grammatical, spelling, or factual changes to another user's
article draft without touching the underlying structure... And the
formatting isn't necessarily an issue anyway as UAs could just as
easily add script-less controls, as they've done with the video
element. That the attribute is currently useless with scripting
disabled is the very reason I've brought this up; it would no longer
be useless if there were a way to send its containing element's
contents back to the server.
Additionally, shunting into a hidden input, while perhaps trivial, is
essentially a hack to work around this missing feature. As an author,
it doesn't strike me as particularly intuitive when every other method
of user-entry can be submitted on its own. What is the user benefit in
making this particular method of data entry require an extra step?
This becomes especially
more relevant when contenteditable is used for editors that don't just
upload HTML; for example, the Google+ editor is contenteditable= but
it's not going to upload the HTML, it uploads structured data.
If the plaintext-only value is spec'd, that's no longer an issue: it
could upload HTML by default, or plaintext when that value is
set—which can obviously be transformed or subsumed into a structured
data set, as G+ must do already.
On Fri, 7 Sep 2012, Mikko Rantalainen wrote:
The contenteditable attribute is meant for low level wysiwyg-editor like
behavior framework and it is not meant to work standalone without
scripting.
Indeed.
Why isn't it? What are the drawbacks?
I'd suggest supporting textarea type=text/html with a built-in HTML
wysiwyg editor if any UA wants to support HTML editing without
JavaScript. In that case, the UA should provide a scriptable method for
detecting for native support of type=text/html. As a result, a CMS
system could fallback to e.g. TinyMCE or CKeditor to emulate the missing
support.
This is actually what old versions of IE did (as htmlarea, IIRC), but it
was dropped. I don't fully understand why, but I'm skeptical of
introducing a new control for this without making sure we don't make the
same mistakes, which means figuring out what those mistakes were.
This is a little hard to search for with simple queries as there are a
lot of results for DHTML scripts of the same name, but I did find the
following article[1] which states that htmlarea premiered in version
5, and illustrates the usage, which is identical to how
contenteditable works; it's just a block-level element rather than an
attribute. Considering the fact that contenteditable was introduced
soon afterward in IE 5.5, it seems reasonable to infer that htmlarea
was essentially a prototype for the same feature. If this is indeed
the case, given that the original concept behind the feature seems to
be a textarea that allows markup, it seems highly likely that
generic editable elements would've been used as form controls were
there a way to do that.
[1]: http://www.siteexperts.com/ie5/htmlarea/page1.asp
On Thu, 13 Sep 2012, Ojan Vafai wrote:
I think this is a problem that we need to address more generally. I'm
not sure what the API should look like, but it's not specific to
contentEditable. I should be able to make a Web Component that submits
specific values with forms based off it's content. If we solve that
problem right, it'll be possible to make contentEditable elements submit
with forms without extra JS code.
Given how easy it is to copy data into a hidden input, why isn't that
sufficient? It would actually be pretty difficult to come up with an API
that is simpler than declaring an input and settings its value...
I don't know that a separate API is necessary here either, but the
hidden input trick doesn't really scale well. Consider the submission
of multiple contenteditable elements, use case being that a user has
privileges to edit certain sections of a document and not others, as
in a template-based CMS. The code would have to look something like
this, at the bare minimum:
var form = document.forms.form;
function stripHTML(html) {
var div =
[whatwg] Font Resize Event
My use case: I have a div with overflow: hidden that contains slides as part of a JavaScript carousel. It has to be overflow: hidden because otherwise the unseen slides are visible/stretch the page. And because each slide is different, the containing div therefore needs to grow/shrink in height depending on the content currently being displayed. This is trivial enough to do, by changing the height to match its contents whenever a slide change occurs, or a resize or orientationchange event is fired, but currently if I increase or decrease the font size, the content can get cut off, or there will be a ton of extra white space, since the div height is out of sync with the height of its contents. This could be easily remedied with a fontresize (or textresize) event. Some existing efforts to fill in this functionality, going back to 2005, demonstrate the utility beyond just this use case: http://www.alistapart.com/articles/fontresizing/ http://www.tomdeater.com/jquery/onfontresize/ http://wellstyled.com/en/javascript-onfontresize-jquery-plugin/ http://dev.sencha.com/playpen/docs/output/Ext.EventManager.html#onTextResize https://bugzilla.mozilla.org/show_bug.cgi?id=303405 While it's true I could use one of the existing scripts I listed, to me they are all unusable as the change detections don't always occur when a Cmd-+/- is issued.
[whatwg] Regarding Examples for rel=tag
Just saw the following change: http://html5.org/r/7347, and while it's certainly nice to have examples, I don't understand why rel=tag *always* applies to the whole document. I think it makes perfect sense in the first example, but my expectation as an author would be for tags within articles to apply only to them, just as header, footer, address, etc. do. Take for example a listing of blog posts which display their respective tags: article header h2My Summer Vacation/h2 /header pContent/p footer pTags: a rel=tag href=/tags/vacationvacation/a, a rel=tag href=/tags/swimmingswimming/a/p /footer /article article header h2My New Cat/h2 /header pContent/p footer pTags: a rel=tag href=/tags/catscats/a, a rel=tag href=/tags/responsibilityresponsibility/a/p /footer /article As currently written, the spec would have implementations tag the entire document with vacation, swimming, cats, and responsibility. Such tags might go together if the author were talking about how it's irresponsible to take cats swimming with you on vacation, but that's not the case here. The only way around this I take it would be for a CMS not to include rel=tag on the links in the listing page view, but then to include them in the single post or permalink views... which strikes me as odd, as both such views typically display more or less the same content, just in different contexts. The semantic of the links being tags doesn't change at all. In fact, WordPress already uses rel=tag in the above manner by default[1], and the Microformats Wiki, which I believed popularized the syntax, states that a tag may just refer to a major portion of the current page (i.e. a blog post)[2], so this conflicts with existing usage. [1]: http://twentyelevendemo.wordpress.com/ [2]: http://microformats.org/wiki/rel-tag#Abstract
Re: [whatwg] Regarding Examples for rel=tag
Didn't mean to go off-list with this. Posting the prior exchange before I respond: On Fri, Sep 14, 2012 at 7:36 PM, Hugh Guiney hugh.gui...@gmail.com wrote: On Fri, Sep 14, 2012 at 5:03 PM, Ian Hickson i...@hixie.ch wrote: Because it was invented before article, so consumers apply it to the whole document and don't know about article. In other words, backwards compatibility. But if a consumer uses article, doesn't that take them out of the backwards-compat category? Also, as I pointed out in the original post, consumers already use rel=tag intending for it to apply only to portions of a page. On Fri, Sep 14, 2012 at 9:51 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Sep 2012, Hugh Guiney wrote: On Fri, Sep 14, 2012 at 5:03 PM, Ian Hickson i...@hixie.ch wrote: Because it was invented before article, so consumers apply it to the whole document and don't know about article. In other words, backwards compatibility. But if a consumer uses article, doesn't that take them out of the backwards-compat category? How so? I mean, Google will work the same (for example) regardless of whether Googlebot supports article or not. Also, as I pointed out in the original post, consumers already use rel=tag intending for it to apply only to portions of a page. Consumers or producers? What matters here is not changing _consumer_ behaviour, so that we don't break pages written with the assumption that they work as they do now.
Re: [whatwg] Regarding Examples for rel=tag
On Fri, Sep 14, 2012 at 9:51 PM, Ian Hickson i...@hixie.ch wrote: Also, as I pointed out in the original post, consumers already use rel=tag intending for it to apply only to portions of a page. Consumers or producers? What matters here is not changing _consumer_ behaviour, so that we don't break pages written with the assumption that they work as they do now. Ah, yeah, misunderstood consumer as a synonym for author. Your reasoning does makes more sense to me now. But, I would still say that if existing consumer behavior is to apply tags to the entire document, then that is simply a limitation of producers not being able to explicitly say that certain tags only apply to portions of the page... which is actually an open issue on the Microformats Wiki for rel-tag[1], something that the HTML spec could potentially solve, and which article seems well-suited to solve. How badly would this actually break existing parsers? Could it really be worse than multiple addresses? Or style scoped? And again, it isn't evident to me that pages *are* written with the assumption that robots work this way, as evidenced by WordPress's assignment of tags on a post-by-post basis[2], marked up with rel=tag[3], posts themselves being marked up with article, and multiple articles being displayed at once in the post listing views. As WordPress is currently the most popular blogging platform on the Internet[4], it represents significant existing usage of the attribute. [1]: http://microformats.org/wiki/rel-tag-issues (No anchor but see 2006-04-06 raised by Evan) [2]: http://codex.wordpress.org/images/b/b6/write1.png (See sidebar section Post Tags) [3]: http://twentytwelvedemo.wordpress.com/blog/ (Inspect element any category or tag link) [4]: http://en.wikipedia.org/w/index.php?title=WordPressoldid=512508447 (first paragraph last sentence)
[whatwg] Submitting contentEditable Content In A Form
I'm developing a CMS and would like to be able to submit user-edited content back to the server, but at present, it's not possible to do this without copying the contents of the edited element with JavaScript into, say, a hidden form field. I think that there should be some mechanism to associate contentEditable elements with forms—maybe the combination of contentEditable=true and the presence of @name creates an implicit form control? The value sent to the server could be equivalent to that element's innerHTML. Thoughts?
Re: [whatwg] Exposing framerate / statistics of video playback and related feedback
On Mon, Apr 30, 2012 at 7:37 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 May 2010, Ian Fette wrote: Has any thought been given to exposing such metrics as framerate, how many frames are dropped, rebuffering, etc from the video tag? It has come up a lot, but the main question is: what is the use case? Web-based non-linear editors. This software already exists—YouTube has one: http://www.youtube.com/editor, Mozilla has one: http://mozillapopcorn.org/popcorn-maker/, and there are/have been several independent efforts as well (http://lifehacker.com/5629683/jaycut-is-a-pretty-awesome-web+based-video-editor, http://www.spacebarstudios411.com/easyclip/, etc). Right now all of this software is alpha-stage, but the kinds of problems they attempt to solve involve: pop-up annotations, synchronized slide shows, clickable video areas, etc. Essentially, they will allow users to author rich multimedia experiences that aren't achievable with a traditional desktop NLE. Even if desktop NLEs were to offer this functionality with an HTML export like Adobe is doing with Flash CS6, it is advantageous to work in the destination medium rather than one fundamentally different; a similar trend is happening right now as web designers are moving away from Photoshop and beginning to design in the browser directly, and I can only imagine the same will happen with moving images, technology permitting. As it stands, frame rate awareness is a feature of NLEs that you would have to try very hard NOT to find. It is quite common for modern camcorders to offer an array of different available frame rates, for instance Panasonic's prosumer models (HVX200, HPX170 etc.) offer at least 20 different fps options: 12, 15, 18, 20, 21, 22, 24, 25, 26, 27, 28, 30, 32, 34, 36, 40, 44, 48, 54, and 60. One of the primary purposes these options is to allow the user to achieve time distortion effects; if your main timeline is 24fps, you could shoot at 12fps and play it back for fast-motion; alternatively 48fps for slow-motion. These are called undercranking and overcranking respectively and have been in use since the dawn of film. A ubiquitous UI paradigm in modern video editing is to have a timeline with a set frame rate, that videos of alternate frame rates can be dragged into to change their effective playback speed. Not only is this useful for artistic time distortion effects, but also pragmatic time distortion, such as mixing 24fps (US film) and 30fps (US broadcast), 24fps with 25fps (European film), etc. with a non-variable output frame rate. Other use cases: - Categorizing/filtering a video catalog by frame rate, such as on a stock videography or film archive site, to only see those match the user's interest. - Video player UI displaying the frame rate so that users can tell if it is worthwhile to attempt playback on a slow connection, or device with limited playback capabilities. For instance such a user might discern that watching a 1080p60 video on a mobile device would take up too much bandwidth BEFORE pressing play and having the video stutter or play too slowly. Similarly, devices could detect this on their own and report to the user. - Frame-accurate subtitle authoring; timing the display of text with a character's lip movements is a precise art and if it is off by even a few seconds, it is distracting to the audience. - NLE that ingests Edit Decision List (EDL) XML files, which denote cuts, transitions, etc. in SMPTE timecode, so editors can work on projects that were originally cut in another NLE. This would be especially useful for desktop-to-web migration. If you have fixed frame rates, it's trivial to do the conversion to and from SMTPE timecode in JavaScript; you don't need any direct support from the media element API. Yes, but we currently have no way of knowing what fixed frame rate we are working with, making this kind of conversion impossible except through pure guesswork. If frame rate is exposed we don't need SMPTE internally.
[whatwg] Outline Depth Does Not Correspond to Sectioning Depth?
I am confused by the current definition of outline depth ( http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outline-depth), which, if I understand it correctly, states that the depth resets with each sub-outline. So, in the following: body h1Document Title/h1 section h2Section Title/h2 section h3Subsection Title/h3 /section /section /body …each heading would have an outline depth of 1, yet for: body h1Document Title/h1 h2Section Title/h2 h3Subsection Title/h3 /body …which is, according to the spec, semantically identical to the previous example, each heading would instead have an outline depth of 1, 2, and 3 respectively. At least, that is how this implementation ( https://github.com/hoyois/html5outliner) behaves; I raised this issue with the implementor and he seems to think it is the correct behavior—if so, why? Wouldn't it make more sense to have the depths be 1, 2, and 3, whether explicit sections are used or not?
Re: [whatwg] Outline Depth Does Not Correspond to Sectioning Depth?
On Mon, Mar 26, 2012 at 8:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: What text are you looking at that implies the outline depths of the headings in the first snippet are all 1? I could not find anything, but the person who wrote that JavaScript implementation seemed pretty convinced that this was the case (https://github.com/hoyois/html5outliner/issues/1#issuecomment-4653452). I figured that having written an implementation he had studied the relevant sections in considerably more depth than I had and second-guessed myself. Looks like it is in fact a bug in the program and not the spec. Thanks for clearing that up!
Re: [whatwg] Outline Depth Does Not Correspond to Sectioning Depth?
On Mon, Mar 26, 2012 at 8:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's possible they'd gotten confused by the fact that the first heading in a section, no matter what rank it is, is more-or-less equivalent to a h1 as far as the outlining algorithm is concerned. Actually his stated reason was that the spec says the outline that s finds itself in which he interpreted as the current outlinee. Perhaps this should be rephrased to the document outline that s finds itself in, or similar, so it isn't confused as a sub-outline.
Re: [whatwg] Validator.nu: Attribute role not allowed on element h2 at this point.
On Mon, Mar 12, 2012 at 8:52 PM, Ian Hickson i...@hixie.ch wrote: The validator is probably just not up to date. Note that that in this case the validator is probably right. If it's just presentational, why are you using h2? It doesn't seem presentational to me. I think you are incorrectly using role=presentational here. I am using it because VoiceOver does not understand hgroup/document outlines yet, and so announces two headings when there should only be one. It is not ideal markup; I'm merely trying to provide a better experience for AT users until new elements and parsing models are understood.
[whatwg] Validator.nu: Attribute role not allowed on element h2 at this point.
Why not? I have this in an otherwise-valid HTML5 + SVG 1.1 + MathML 2.0 + RDFa Lite 1.1 document: hgroup h1Company Name/h1 h2 role=presentationTagline/h2 /hgroup Spec says: Authors must not set the ARIA role and aria-* attributes in a manner that conflicts with the semantics described in the following table, except that the presentation role may always be used.
Re: [whatwg] di? Please?
On Fri, Feb 3, 2012 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: There are a number of places in HTML where it would be nice to be able to group things together -- just look at how often people stick divs in their pages for no purpose whatsoever other than styling. This shouldn't be necessary. It's a limitation of CSS. Then why is section in the spec?
Re: [whatwg] di? Please?
On Sun, Mar 4, 2012 at 5:07 PM, Ian Hickson i...@hixie.ch wrote: Then why is section in the spec? To make it easier to move subsections around without having to change all the h5s to h4s and so forth. That's it? So the fact that it provides explicit grouping and styling are unintentional side-effects? I don't think I've come across a single person or article discussing section, in the time since its introduction, ever even mention rearranging subsections as a benefit at all, let alone the *primary* benefit. That's not even mentioned in the spec itself… Furthermore, for h*, the spec provides examples of semantically equivalent document structures, one with sections and one without, concluding: Authors might prefer the former style for its terseness, or the latter style for its convenience in the face of heavy editing; which is besty [sic] is purely an issue of preferred authoring style. If the decision to use section or not is purely an issue of preferred authoring style, what makes di any different? Why is in inappropriate to have a stopgap grouping element for dl while CSSWG works on a syntax for pseudo-grouping (if they even decide to do so), yet perfectly fine for sectioning content?
Re: [whatwg] di? Please?
On Mon, Mar 5, 2012 at 12:09 AM, Ian Hickson i...@hixie.ch wrote: The only thing it adds to the grouping is the ability to have a subsection that is then followed by more content from the subsection's parent section. You couldn't do that with hx alone. However, for section that's more of a negative than a positive, really (it makes more sense for aside, nav, and article; section only allows it for consistency). In what ways is that a negative? The spec doesn't generally include design rationale. (If anyone would like to help maintain our rationale documentation, please let me know. We're always in need of volunteers there.) What type of work is involved? di doesn't exist. The ability to have multiple types of authoring style isn't the reason for section's existence. It's just a side-effect of now having two different ways to mark up sections. It's not actually a good thing in language design to have multiple ways to do something (despite what Perl might have us believe!). HTML is full of multiple ways to do things: a run of text can avoid p and be the child of a div if the author prefers, a footer can be at the bottom or top of a section, authors can continue to use Microformats despite the existence of microdata, etc. If language idealism was a tenable goal on the Web then the WHATWG wouldn't exist and we would all be using XHTML 2 right now (which had di, for that matter). section wasn't introduced as a stop-gap measure. There's no such thing as a stop-gap measure on the Web. We can't add something then remove it. Once we've added something, it's part of the platform, forever. That's why we have to be careful to only add things that make sense on the long term. I only said stopgap because you posited CSS grouping as the ideal we should be striving for, when this method would work today. I actually don't think this should be taken out at a later time, as CSS grouping only addressing the issue of styling. It does not address the fact that—as I outlined in my original post—it is impossible with dl's current parsing model to specify a named value followed by an unnamed value, since the unnamed value would be subsumed into the preceding group and be interpreted as an alternate value for it. The converse (an unnamed value followed by a named value) *is* possible. The spec claims that the order may or may not be important, yet this forces the author to write things in a specific order, which may violate what data they are trying to describe, or in what way. To illustrate: dl ddNameless value/dd dtName/dt ddValue/dd /dl dl dtName/dt ddValue/dd ddNameless value? Nope, alternate value for Name./dd /dl Whereas wrapping either or both Name/Value and Nameless value in di would mirror what is already allowed, but free the author up to use the appropriate order rather than compromising semantics with multiple dls or non-dls.
Re: [whatwg] Allow Fallback Text to Render Section Titles in Outlines
On Sat, Feb 11, 2012 at 7:47 AM, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: Doesn't the spec imply it should? That depends on whom you ask. I would think that it does, but since it doesn’t explicitly say to parse alternative text for replaced elements, implementors could simply interpret it as “display any child text nodes without further processing”, which seems to be the case in existing implementations.
[whatwg] Allow Fallback Text to Render Section Titles in Outlines
Currently when I run markup like this through outliner programs, they return blank section titles: h1img src=/img/logo.png alt=Company Name //h1 h1 svg g titleCompany Name/title path / … /g /svg /h1 I feel that in both instances, Company Name should become the section title for the respective section. Yes, I could use CSS image replacement to work around this issue, but that is a hack—it isn't semantically accurate as the image is not a decorative background, but in fact a important piece of content which should still appear with CSS off. Similarly, repeating the alternative text outside of the image and hiding it with CSS would be redundant, both visually and to screen readers, with CSS off. I could also use CSS @font-face rules to embed the logo font and just use text, but not all fonts have licenses that permit doing so; many explicitly forbid @font-face linking or specify that only graphical renderings are allowed. I also often receive fonts from clients that have modified letterforms, but have not been made into general-use fonts, which makes embedding impossible. So, text-as-graphics, while not ideal, is sometimes the only option. Since both img and svg fall under h*’s content model (phrasing content), it only makes sense to allow their fallback text to be used as section titles. This would aid accessibility and meet author expectation—in addition to mine, see for instance this person, who filed it as a bug under a particular implementation: http://code.google.com/p/h5o/issues/detail?id=5#c0.
[whatwg] Media Player Seek Bars: Problems and Suggestions
I'm currently creating a custom HTML video player UI. What I'm trying to achieve is a seek bar control—a horizontal slider that allows the user to seek to a specific point in time. Right now the basic functionality of this can be achieved using a range input with a max value set to the video's duration, and which sets the video's currentTime onchange. However, there are two problems with this: The first is that I'd like to be able to show the user, before selecting a point in the range, what point they are about to seek to. At present, even if there is an element that exposes currentTime to the user, there's no way to show them what currentTime *will* be until they actually select a point on the range. Although I realize range inputs are meant to be imprecise, it's often helpful to be able to see more precise values one at a time, so that if there is a value they're aiming for, they can find it or get close enough with less trial and error than blind selection. It has become a ubiquitous UI convention on the Web to provide time code and/or frame previews in a tooltip as the user scans the seek bar (but before seeking). This can be seen for example on YouTube, Vimeo, Hulu, blip.tv, Brightcove, Firefox, and many JS library players. And although the effect is most common in video players, it would be helpful in audio players, or any other situation where a user wants to browse available options within a range without committing to any right away and triggering an unwanted action. One solution would be to introduce some DOM interfaces, for instance: - A preChange event that fires while a range input is hovered over, as the coordinate of a pointing device is advanced in either direction along the input's axis. - A readonly attribute preValue that holds the value that corresponds to the input's currently pointed-to coordinate. That way, an author could write a script that modifies a range input's title attribute, etc., with the prospective time. The second problem is that at present, range inputs are not quite sufficient semantically for marking up seek bars. Seek bars typically display not only a thumb, but also a progress bar that displays what percentage of the video is loaded. Obviously, we have progress for this, and so theoretically one could use both a range input and a progress bar together, this falls short for a few reasons: - They are separate elements when seeking UI is almost universally represented as a single control. Although it's possible to position a range input on top of a progress bar using CSS, for users with CSS off, it takes up twice as much space as it needs to. - Seek bars typically have 3 distinct progress indicators: not buffered (transparent/no color), buffered (translucent color), and buffered + played (opaque color). Currently, progress bars can only display 2 styles: translucent and opaque. - When seeking to points that have not yet been buffered, some seek bars will leave the unbuffered portions translucent, starting the played + buffered color not from the minimum value point but from wherever the user seeks to. Advancements in CSS would not address this as there's only min, value, and max to work with; there's no way to specify [a] concurrent value(s) to represent the discontinuous progression. Possible solutions would be to address these shortcomings in progress and then somehow specify that a range input and a progress bar are connected and should be rendered as a single UI in supporting UAs and separately as fallback; or, more simply: introduce input type=seek explicitly for controlling media elements. Thoughts welcome! -Hugh
Re: [whatwg] di? Please?
On Tue, Jan 10, 2012 at 2:52 AM, Jordan Dobson jordandob...@gmail.com wrote: Sounds like what you want is flex box. Have you looked at that yet? I don't know flexbox too well yet—how would one use it to create a columnar dl? From what I can tell though, it still wouldn't allow me to style dt/dd pairings as a single unit, which is actually the root issue here. On Tue, Jan 10, 2012 at 3:04 AM, Bruce Lawson bru...@opera.com wrote: Seems to me no need to add a new element. If div could be a child of dl then you could use that. However, it can't. I don't know why, though. I would probably avoid div in this case simply because it's supposed to be semantically blank; in the example I gave, if section were div instead, it would be completely appropriate for an outliner to regard that as two sections instead of three. So, if we're going to reuse an element like that, I'd lean more toward section—although I can't recommend this either as it implies that bits and pieces of dls should show up in the document outline. I think that di or li or even dl children of dl (all of which have been suggested in the past) make the most sense here. As a developer it doesn't matter to me which one it is; I could just use the flexibility.
[whatwg] di? Please?
As I understand it, the main reason for rejecting di was that it solves a problem that is allegedly CSS's job, but as an author who uses dls quite extensively, adding a grouping element would really make my life a lot easier. Yes, my most common problem with dls is styling them, but it's hardly CSS's fault. What kind of styling am I attempting to do? Mostly, to arrange them in columns. Why not use table? Because the data is at most two-dimensional (i.e., serial, not tabular) and consists of definitions rather than arbitrary data. Why would I want to to arrange the data in this way? The same reason I would want to arrange most things in columns: to use vertical space efficiently when I have it. I've tried, and as far as I can tell, this can't be achieved with floats. Even if it can, it's prohibitively unintuitive enough to someone with considerable CSS experience. The only way I have done it is with absolute positioning, which of course takes you out of normal flow and into fixed coordinate positioning; hardly tenable considering the flexibility requirements of fluid, and now responsive designs. Even recent additions like CSS3 columns are a blunt instrument in this regard, which often result in widows/orphans unless height is manipulated manually to force everything into place (a nonstarter for separation of concerns). Yet, I can achieve this easily with uls and with tables, with headings and paragraphs inside of various containers; I can do it with essentially every other data structure but dl, and that's no coincidence: dls are notoriously hard to style specifically because they're loosely-structured; they lack the grouping semantics which are paradoxically abundant in other content models. Because of this, I have in the past resorted to either: A.) choosing a less-semantically-accurate, but more flexible structure; or B.) splitting the dl into two dls. I tend to opt for B. simply because I want to retain the dl semantics, but it's still less-than-desirable because the motivation for doing so is purely presentational. Sibling dls are as silly as sibling ul/ols: if there's no reason to have other content between them (such as an explanation about what the second list represents), there's no reason not to enumerate them all in the same list. Yet, it's the only practical way to achieve this effect. I have a feeling most authors would opt for A., however, which diminishes the utility of dl by making it even more rarely used. The way I see it, di has more or less identical use cases to section. Despite the fact that we have an outlining algorithm that will automatically determine the structure of your content without using section at all, authors are still free to use grouping mechanism to make sectioning explicit, which is necessary to avoid ambiguity. Take this for example: section h3foo/h3 pbar/p /section section h3baz/h3 pqux/p /section pquux/p …where the absence of sections would result in two titled sections, rather than the desired: three sections, two of which are titled and one of which is untitled. This is in no way different from the following: di dtfoo/dt ddbar/dd /di di dtbaz/dt ddqux/dd /di ddquux/dd …where the absence of dis would result in two named values, rather than the desired: three values, two of which are named and one of which is unnamed. Simply put: just because the parsing algorithm is well-defined and we can imply association sans-container, that doesn't mean authors (like myself) won't want finer-grained control over grouping. Is there a compelling reason why, given the current dl content model, it is possible to create a list of: nothing but unnamed values, nothing but valueless names, an unnamed value followed by a named value, a named value followed by a valueless name, but NOT a named value followed by an unnamed value—what makes that last scenario any less useful than all of the others? If anything it's probably the *most* useful, since valueless names and nameless values can already be represented by ul/ol.
[whatwg] Fwd: Allow Select SVG Elements In head
Cameron McCormack forwarded this proposal to public-svg-wg a year ago (thanks, Cameron!) but no one commented on it, so I'm reposting it here. Is this something the SVG WG is willing to do? Thanks! -Hugh -- Forwarded message -- From: Ian Hickson i...@hixie.ch Date: Mon, Dec 6, 2010 at 9:35 PM Subject: Re: [whatwg] Allow Select SVG Elements In head To: Hugh Guiney hugh.gui...@gmail.com Cc: whatwg wha...@whatwg.org On Fri, 27 Aug 2010, Hugh Guiney wrote: I'm authoring an XHTML host document with namespaced inline SVG and XLink. I have vector images that recur throughout the site. I'd like to implement SVG's defs and use to reduce the file size of the document and keep style separate from content, as with CSS. If I put an SVG tree with defs anywhere in the XHTML document, other trees with use xlink:href will correctly reference it, as tested in the latest public release Gecko, Webkit, and Opera. So the question becomes, where do I put it? The most obvious answer seems to be head, since, like CSS definitions, this is metadata being defined for use elsewhere in the document. The only problem is, Validator.nu doesn't like it: Error: SVG element svg not allowed as child of XHTML element head in this context. (Suppressing further errors from this subtree.) Same error when ditching the root svg and including only defs, the result of which still works in all but Opera. This error can be avoided if the defs tree is put in the XHTML body, but then there is blank space the size of the defined shapes at the top of the document in all 3 engines. A workaround is to give svg a @width and @height both of 0. But leaving the definitions in the body when they technically don't represent contextual content strikes me as non-semantic. My proposition would be to simply spec a subset of SVG consisting only of metadata elements as valid in HTML's head context. This could be just defs—I'm unsure if there are any other elements that fit this definition since I am relatively new to SVG; but in either case it'd aid semantics and is already supported in today's SVG-capable browsers. This is an interesting idea. I would recommend approaching the SVG working group and suggesting that they define the content model of svg and other SVG elements such that there's two ways to use it: one where svg is considered embedded content, and one where it's considered metadata content, with appropriate restrictions on the latter. With such a set of definitions in place, the HTML spec's model would just work (it already refers to the content model of head as just metadata content, for instance). -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Call for Clarification of the Menu Element Et Al.
Hey All, I was in the process of coding a prototype for a site I'm working on when I decided that certain nav's should actually be menu's. While the basic concept is apparent, unfortunately, with zero browser implementation at this time, it is impossible to actually know what my markup is doing (or rather, would do). So I looked to the spec for guidance, but ultimately it leaves me very confused. These are some points I feel could be addressed, in no particular order: 1. How does one know whether to wrap a nested menu in li or leave it as a direct child element? Are these semantically-equivalent coding styles or is there a difference? 1.1. When marking up a menu specifically with *multiple* menu items, is menu/li the only way to do it or would menu/menu also be appropriate? 2. What is the difference between a menu containing command elements and a menu containing form controls? Do they merely favor future and legacy UAs respectively? 3. The spec should provide examples demonstrating when it is better to use context vs. toolbar vs. list, as these are very similar in concept. I could easily see them being misappropriated. 4. In the first example, what renders the button UI? Is it menu[@type=toolbar]/li, or li/menu? Or is it implied CSS? 4.1. Furthermore, should this example even depict a button UI, given that most graphical interfaces display top-level toolbars as text/icons against a [mostly] solid background Were a UA to render the example as demonstrated, would designers not have to style away the button appearance in order to achieve a look feel that matches user expectation? Obviously, this would not be the case in secondary (or n-ary) toolbars, for instance as in word processors, where everything below the initial row are usually buttons. Could there be a way, then, whether in markup or CSS, to denote whether a toolbar is displayed as a primary/top-level toolbar or not? 5. Provide more/graphical/clearer examples, to aid both browser vendors in deciding how to implement the elements, and authors in having an idea of what result they can expect from using them. The NPC form, for instance, does not say exactly what it is or does, nor does it represent a common UI convention. The only thing I can think of that comes close is Spotlight in OS X (if I'm interpreting it correctly), which I don't think I've ever seen in a [presumed] game before. 6. How is the command element rendered within a menu context when JavaScript is disabled? Is it meant only for non-essential actions? If it isn't, shouldn't it be able to be non-empty, so it can fallback to links or buttons? Or is the only possible fallback replicating every command with form controls that aren't direct children of the parent menu? 6.1 On that note, why is the spec enabling the use of unstyled spans to achieve alternative rendering? Doesn't this give meaning (however contextual) to an element that is supposed to be semantically neutral? 7. Is the menu element always to be rendered in-page or could it be displayed within the OS itself? Kroc Camen (suggests)[http://camendesign.com/blog/stop_this_madness] the latter but at present there is nothing in the spec about such an implementation. If this is left up to the UA how will developers know how/if to style it without using browser detection? Guidance, insight, reactions? Thank you, Hugh
[whatwg] Allow Headings As Children of summary
I am authoring a video portfolio page using Kroc Camen's Video For Everybody code http://camendesign.com/code/video_for_everybody for each piece. In this code he includes a download section for users who may be unable to play the video live on the site, e.g. because they lack both HTML5 (or the proper browser codecs) and Flash support. As this hopefully won't be a problem for most users, I would prefer not to distract them with this information unless they decide they need it, and therefore have chosen to mark it up with details. However, I feel this Download portion is also important enough to be its own subsection, as it is distinct from the surrounding content and may be useful to navigate to as part of the document outline. The obvious way to accomplish this would be for instance: details summaryh1Download/h1/summary ul lia href=video.mp4MP4/a/li lia href=video.oggOGG/a/li ... /ul /details but this is invalid via the current spec which only allows summary to contain phrasing content. I could give it its own heading outside of details, but this would be redundant as I would have to do duplicate the heading text in both h1 and summary, and it makes the expansion action area ambiguous. A mouse user might encounter the collapsed menu and not know whether to click on the heading or the summary to expand it—or even just consider it the author's error, or a glitch. Even if I were to use different text for each element, I find few things to be appropriate in this context that are not similarly redundant. Download for the heading and Video Format Options for the summary? The fact that the list is of format options would be reasonably apparent by the link text for each item indicating MP4, OGG, etc. My proposal to address this would be to allow heading content under summary—or, conversely, to allow summary to be used as a descendant of details rather than just the first child, such that you could wrap headings around it, as phrasing content is already allowed under details. But, the latter changes structure and therefore parsing whereas the former is simply a validation change.
[whatwg] Validator.nu Bug: Error: XHTML element noscript not allowed as child of XHTML element head in this context.
I am using noscript as permitted, In a head element of an HTML
document, if there are no ancestor noscript elements. but still
getting an error from Validator.nu saying it's not allowed.
Settings:
Encoding: as set by server/page
Schemas: http://s.validator.nu/xhtml5-aria-rdf-svg-mathml.rnc
http://s.validator.nu/html5/assertions.sch http://c.validator.nu/all/
Preset: XHTML5+ARIA, SVG 1.1 plus MathML 2.0
Parser: XML; don't load external entities
XMLNS Filter: [blank]
[ ] Be lax about HTTP Content-Type
[ ] Show Image Report
[x] Show Source
Original input:
?xml version=1.0 encoding=utf-8?
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml;
head
title/title
script type=text/javascript src=http://use.typekit.com/uys3rrk.js;/script
script type=text/javascripttry{Typekit.load();}catch(e){}/script
noscript
link href=/styles/typekit-fallback.css rel=stylesheet media=all /
/noscript
/head
body
p/p
/body
/html
Result:
Error: XHTML element noscript not allowed as child of XHTML element
head in this context. (Suppressing further errors from this subtree.)
From line 6, column 1; to line 6, column 10
/title↩noscript↩link
Contexts in which element noscript may be used:
In a head element of an HTML document, if there are no ancestor
noscript elements.
Where phrasing content is expected in HTML documents, if there are no
ancestor noscript elements.
Content model for element head:
If the document is an iframe srcdoc document or if title information
is available from a higher-level protocol: Zero or more elements of
metadata content.
Otherwise: One or more elements of metadata content, of which exactly
one is a title element.
[whatwg] Allow Select SVG Elements In head
I'm authoring an XHTML host document with namespaced inline SVG and XLink. I have vector images that recur throughout the site. I'd like to implement SVG's defs and use to reduce the file size of the document and keep style separate from content, as with CSS. If I put an SVG tree with defs anywhere in the XHTML document, other trees with use xlink:href will correctly reference it, as tested in the latest public release Gecko, Webkit, and Opera. So the question becomes, where do I put it? The most obvious answer seems to be head, since, like CSS definitions, this is metadata being defined for use elsewhere in the document. The only problem is, Validator.nu doesn't like it: Error: SVG element svg not allowed as child of XHTML element head in this context. (Suppressing further errors from this subtree.) Same error when ditching the root svg and including only defs, the result of which still works in all but Opera. This error can be avoided if the defs tree is put in the XHTML body, but then there is blank space the size of the defined shapes at the top of the document in all 3 engines. A workaround is to give svg a @width and @height both of 0. But leaving the definitions in the body when they technically don't represent contextual content strikes me as non-semantic. My proposition would be to simply spec a subset of SVG consisting only of metadata elements as valid in HTML's head context. This could be just defs—I'm unsure if there are any other elements that fit this definition since I am relatively new to SVG; but in either case it'd aid semantics and is already supported in today's SVG-capable browsers.
Re: [whatwg] Video source selection based on quality (was: video feedback)
Thanks for your insight Silvia. On Wed, Feb 10, 2010 at 2:47 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Firstly, I think that explicit user choice isn't a problem. As a content provider, you have several means of doing this user choice: 1) You can provide in a single (admittedly javascript-based) video player interface an option to the user to switch between source files of different quality (bitrate, width x height, audio samplerate, and whatever other choices you make for differently encoded content). This is what YouTube does in their latest players, e.g. 360p / 480p / 720p choice (though this is not really a quality measure, but only a measure of width x height, but since the display size is not changed in YouTube, it actually is a quality setting). I can *maybe* see this feature being a video player UI component (more on why in a bit), though not a JS-based one. I imagine people with slower computers/connections and/or in more restrictive environments, who probably stand to benefit the most from this, would be more likely to have JS off. Additionally, it would require document authors to take on the responsibility of scripting their own content selection algorithms (unless there's a standard library that everyone just copies and pastes), which seems unnecessary given the fact that resource selection is already capable of being done by the browser and/or server. Also, the choices don't *only* measure width x height, but also indicate of how frames are scanned: p for progressive and i for interlaced, which have a direct impact on both file size and perceived image quality. Although, the label p is redundant in YouTube, since AFAIK, it automatically de-interlaces whatever you upload. The problems with making this a video UI component are that: It'd be heavily abbreviated. YouTube is using an industry convention that has only entered consumer parlance due to HDTV marketing (just Google 720p vs. 1080i or 1080p TrueHD), which ONLY specifies height and scan type, since the rest of the information is implied due to engineering and broadcast standards, e.g. 1080p implies 1920x1080 29.97 or 23.976 fps progressive scan; 720p implies the same but at 1280x720. But 360p doesn't imply anything, because there's no standard that defines it, and once you hit the SD level (480p and below), there are two different display sizes depending on the pixel aspect ratio. But even if we had a standard, YouTube further dilutes the meaning of these abbreviations since they now also have a toggle button (depicted as two arrows at a right angle) that expands or contracts the player but leaves the quality setting the same. So if you select 360p, and decide you want it to fill more of your screen, it will, but then it's no longer 360 pixels tall because it's been scaled. The alternative would be to specify the video information in full, or in a partially-abbreviated form. But then you'd have to cram stuff like 1920x1080p24 (Scaled to 1280x720) into the UI, which crowds the other controls and hinders the viewing experience. The other thing is that so much goes into video. Yes, (bitrate, width x height, audio samplerate go into it, but whatever other choices you make for differently encoded content). covers a huge spectrum, as I previously outlined in the original thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024520.html. All of this criteria is potentially useful, so maybe the goal for now should be to prioritize them in the order of importance they'd be to the average user and implement a high-ranking subset. 2) If users log in to use your content, you can ask them to provide a default setting, just like YouTube does it in their Account Settings (as Hugh describes below). This may be fine for video portal sites, but not every page utilizes logins. Most people just want to share a video they made or like with their audience, the same way they would an image. And they may be using a free blogging service that doesn't allow them to implement additional features. I also find it impractical to require a login system to be in place just to ask users to select a content quality preference. 3) Even if users don't log in, you can have a button on the side of the video (and a once-off splashscreen if you so like), which allows users to set and change their preference and leave a cookie to remember their choice. I'd be OK with cookies as an interim solution but they're not ideal, since they'd require setting new preferences for every site visited while the clients' connection and computational speeds would stay more or less the same. All of this is based on the premise that the user either knows what their pipe and their computer can take, or experiments with it until he/she is happy. Well, they don't always have to know off the top of their head. P2P programs often allow one to run automated tests to estimate the speed of his/her current connection. If similar
Re: [whatwg] Video source selection based on quality (was: video feedback)
On Mon, Feb 15, 2010 at 7:07 PM, Tim Hutt tdh...@gmail.com wrote: Erm, what? The 360p refers to the 'native' resolution of the video file youtube sends. If you play a 360p video fullscreen, it's still only got 360 lines; they're just scaled up. It would be meaningless if the number referred to the final playback size since that is independent of the video quality. By lines, do you mean TV (or scan) lines? TV lines and pixels can both be used to describe image resolution, but they aren't the same thing. The difference is very technical and isn't relevant to this conversation but essentially, TV lines pertain to analog systems and pixels pertain to digital systems. And in the digital realm, magnification is achieved through interpolation: since the source image has less pixels than the destination image, a resizing algorithm must invent pixels to fill in all of the unknown values in the target image, based on the known values in the source image. The result is a best guess of what the image might look like at that resolution. The pixel count has changed; it is therefore new data and not the same as the input. The way YouTube has it now is meaningless since the player doesn't expand when you change the height (that's what that number is supposed to indicate). The older standard/HQ/HD made more sense.
Re: [whatwg] Video source selection based on quality (was: video feedback)
On Mon, Feb 15, 2010 at 8:09 PM, David Singer sin...@apple.com wrote: I think I agree with Tim here. When you ask to watch 360p content, you are asking for content that has 360 lines of pixels to be displayed to you. Right. You're not asking for whatever is displayed to you to occupy only 360 lines of pixels on your display. That's what YouTube's doing, though. In compacted mode, YouTube displays *everything* at 640x360. In expanded mode, everything is displayed at 854x480. That's regardless of whether you select 360p, 480p, 720p, or 1080p—which are all *supposed* to be abbreviations for different frame sizes. What you are *actually* selecting is which of the multiple encodes YouTube automatically creates of your video to act as the source video, which is then scaled to 640x360 or 854x480 depending on the selected player size. Using the [pixel height][scan type] notation in this way is misleading, since they're no longer semantic (UNLESS you know what's going on behind-the-scenes, which most people don't). Video is already very confusing and labels like that, with no explanation, don't help matters. Yes, when it is shown larger, then filtering etc. is done to avoid pixel-doubling blocky artifacts; this does not increase (and, we hope, not decrease) the amount of information in the scene. Interpolation is not pixel-doubling—it can be done in that way (i.e., where every source pixel is mapped to a multiple of itself), but there are many different algorithms that determine how an image is to be scaled and they all work differently with varying levels of visual degradation and processor intensity. While it is true that the amount of information in the SOURCE image does not change, the amount of information in the RESULT image *does*, simply by nature of the fact that it is no longer the same image. This is far and away from what I was originally discussing though. If you want to learn more about how image interpolation works this is a good primer: http://www.cambridgeincolour.com/tutorials/image-interpolation.htm With the advent of higher-resolution displays, and the ability to use CSS with HTML to set 'sensible' sizes of video relative to other page content, the assumption that video will always be displayed in a 1:1 ratio of source (coded, transmitted) pixel to display pixel is increasingly untenable. I never said that video will always be displayed 1:1; that's completely unrealistic. Every TV currently in production scales the incoming image in some way with default settings. This is because most consumers can not cope with letterboxing and manufacturers need a way to sell bigger and bigger screen sizes even even when the content doesn't fit snugly between each corner. What I was saying was that we shouldn't refer to something by a name that means something else. Yes, if you select 1080p on an HD YT clip, it'll use the 1080p file—but it WON'T fill up Joe's brand new 1080p computer monitor until he goes into fullscreen mode. But how is he supposed to know that he has to do that? It SAYS 1080p down at the bottom, after all. For all he knows that's the size of the video. Similarly, Jane may be thinking about buying a new monitor herself, but after seeing how small 1080p is on YT, decides it's not worth it. And when other established terms are used, like 480p—which, in virtually every other context, refers to 720x480, the most common of the acceptable resolution for DVDs—yet the video is *854*x480, that's also confusing. Ted could download such a 480p clip and attempt to burn it, only to discover that his authoring program won't accept that format. What is boils down to is that video formats are *already* very confusing, and that fact does not need to be compounded by careless labeling. -Hugh
Re: [whatwg] Video source selection based on quality (was: video feedback)
On Tue, Feb 16, 2010 at 12:35 AM, Gregory Maxwell gmaxw...@gmail.com wrote: ... Pixel aspect ratios. This whole discussion has been painful to watch. I know what pixel aspect ratios are. All too well, actually—for instance, the square-pixel equivalent of 720x480 widescreen can be either 853x480, 854x480, 856x480, 864x480, 873x480, or 875x480 depending on whom you ask. What fun! I actually attempted to explain this in another thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024541.html So, yes, I realize that those dimensions are PAR-compensated. Most users don't, which is why the shorthand form doesn't do them any favors.
Re: [whatwg] Quality Values for Media Source Elements
On Mon, Dec 14, 2009 at 4:08 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: I would almost consider simply using low quality and high quality as quality distinguishers (and maybe medium) and leave the actual choice of encoding to the hosting entity. Right now, may sites provide only two choices for Desktop: SD and HD, plus one for mobile. The device can be separated by the device-width as Eric described. Except it can't—at least, not entirely. Since the size of a video image is the result of multiplying the width and height by its pixel aspect ratio, the pixel count of the video does not necessarily match that of the device playing it back. For instance, on a DVD, both fullscreen and widescreen movies are stored at the same resolutions, but with different pixel aspect ratios (i.e., the shape of the pixels are not necessarily a 1:1 square, as on computers). According to the D1 DV standards, fullscreen pixels have a width-to-height ratio of 4320/4739 (~0.9). So a 720x480 fullscreen image on a square-pixel device would have to be displayed at ~656x480 pixels to retain its proper aspect ratio. By the same standards, widescreen pixels are 5760/4739 (~1.2), so a 720x480 widescreen image would have to be displayed at ~875x480 pixels. Therefore, screen and (min-device-width: 720px) would not work for all 480i/p content. Either the PAR would have to be read from the file itself—the storage of which differs from format to format—or the author would have to specify it. Which is also problematic since not everyone knows what PARs are, and even when they do, not everyone uses the same pixel shape definitions: MPEG-4 says widescreen pixels are 40/33, which is *close* to the D1/DV definition but not quite: this results in a ~873x480 square-pixel image. And due to rounding, there is also a conventional habit of specifying a PAR of 6/5 (exactly 1.2), resulting in 864x480. Apple on the other hand defines it as 32/27, resulting in ~853x480. So even with the same source content, you may be looking at as many as 4 different rendered sizes depending on the device manufacturer. So if you specify the PAR according to one standard, a device built according to another may not recognize it as playable material, even though it is fully capable of playing it back. Though this COULD potentially be solved by taking aspect ratio error into account when processing the media query. So say for any specified PAR that doesn't match a PAR the device can support exactly, if the ratios turned out to be the same rounded to a certain decimal point, that would count as a match and the device would simply render it according to its standards. This *somewhat* defeats the point of specifying PARs exactly, but at least it'd be good enough as the difference would be too insignificant for most people to notice. SD and HD - while also changing between aspect ratio - are mostly a choice between lower bandwidth use and higher bandwidth use, which are taken as equivalent to low and high quality by users. Since there will likely be a higher bitrate HD version joining in the future, it will then turn into SD, HD and HD2 - which equates to low, medium, high. Over time, SD will fall aside and leave medium and high. Then, if another higher quality comes in, they can be redefined to low and medium. Thus, keeping these fuzzy specifiers, we stay future-proof and leave the actual choice of what low and high means to the respective hosting site, which will make the format choice according to current standards. I'd prefer giving actual levels (low, medium, and high) rather than a number between 0 and 1, because they make it comparable between hosting sites. If I choose to have low on YouTube, I will likely want low on Dailymotion and Hulu, even if those sites decided to use completely different encoding parameters for their low and high quality versions. I can agree with this proposal as far as quality = data rate is concerned. As for any of the other criteria, they'd have to be addressed differently. On Mon, Dec 14, 2009 at 10:59 AM, Aryeh Gregor simetrical+...@gmail.com wrote: It depends on the application. But in any event, HTML can never possibly do everything JavaScript does, so at some point the answer needs to be use JavaScript. Nor should it. But if you're doing something in JavaScript, there *should* be a functional alternative in plain HTML when it's turned off. That means if you've got an AJAX application, even with JS turned off a user should still be able to interact with the server synchronously. If you had all of your content negotiation in JS, however, there could be no alternative, as the lack of one would have been the reason to use JS in the first place. I don't follow. If authors *were* willing to use content negotiation, to the contrary, there would be no need for source. You could just write video src=foo/video in your markup, and configure your server to serve foo.mp4 or foo.ogg depending on
Re: [whatwg] Quality Values for Media Source Elements
On Sun, Dec 13, 2009 at 7:26 AM, Aryeh Gregor simetrical+...@gmail.com wrote: JavaScript is an integral part of HTML to all intents and purposes. HTML itself does not and should not try to cover use-cases that are already adequately covered by HTML+JavaScript -- there will always be things that are better handled by a general-purpose scripting language. Of course, moving something into HTML might be valuable because it makes the feature easier for authors to use, but that needs to be weighed against the cost of browsers having to implement it rather than some other feature. JavaScript is a crutch that far too many applications are relying on for major functionality lately. JavaScript should enhance a Web experience, not supplant it. Well, yes. On the other hand, almost nobody actually uses content negotiation, so I don't think that supports your case. If no one uses content negotiation then there is no need to have the source element at all. Well, no, because there's almost no functional difference between XHTML and HTML except that the former is more likely to break due to typos or minor bugs. Plus, virtually no site actually provides both XHTML and HTML. Actually, virtually no site provides real XHTML at all. So I don't bother specifying a preference for either. If you do, I rather suspect that makes you one of a few hundred people at most, out of billions of web users. So maybe you could pick an analogy that's more realistic? XHTML and HTML are interchangeable with any other two technologies in that example. PDF and Word, HTML and RSS, RSS and XHTML... the point isn't whether most site authors are offering those two in particular; the point is that on a platform that supports content negotiation, it makes no sense to outsource it to another technology, making authors reinvent the wheel simply because not enough people are using wheels. On the other hand, every single video site already does allow you to specify quality, and I've never had a problem with this. It's a simple control that's only there when you want it, and you can easily figure out if you actually want higher or lower quality in any given case. It's simple for an end-user; not necessarily so simple for authors to implement. On Sun, Dec 13, 2009 at 5:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: The analogy with the source selection algorithm for mime types on a server doesn't work well, because there is only one dimension upon which to choose a source file: mime type. Here, we have several dimensions, making any automated choice a challenge. I do agree with this. On Mon, Dec 14, 2009 at 12:12 AM, Eric Carlson eric.carl...@apple.com wrote: Certainly! WebKit evaluates the query in the 'media' attribute if it believes it can handle the MIME type. If the query evaluates to true, it uses that source element. If it evaluates to false it skips it, even though it could (in theory) open the movie. For example, one of our layout tests [1] has the following : video controls source src=content/error.mpeg media=print source src=content/error2.mpeg media=screen and (min-device-width: 8px) source src=content/test.mp4 media=screen and (min-device-width: 100px) /video The test fails if the video element is instantiated with anything but test.mp4. This seems extremely useful. How many media features are implemented? Currently, though, the CSS3 Media Query spec doesn't cover enough metadata to make this as useful as it could be. On Mon, Dec 14, 2009 at 1:54 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Indeed it seems to me the solution to the quality problem should then be done through the media attribute. I am not sure yet how to, because we have no definition for what a low quality or high quality video is other than some form or SD vs HD and lower resolution vs higher resolution and lower bandwidth vs higher bandwidth. Well, we could certainly define them as they'd be defined *today*, but as HD becomes more and more commonplace it will effectively stop being high definition, even if the name sticks. And, what one person considers low quality, another person may consider high quality, and vice-versa, depending on the capabilities of their machine and the type of content they're used to seeing. Which is why it doesn't make sense to specify absolutes, and why I proposed using relative values. If we're to be more granular though, the biggest barrier to implementation is the fact that, as you said, video is multi-dimensional: there are MANY different factors that can affect quality, viewing preference, and/or playback compatibility. Here is a non-comprehensive list off the top of my head: * Aspect Ratio (or Width and Height) * Pixel Aspect Ratio (or Relative Pixel Width and Relative Pixel Height) * Display Aspect Ratio (or AR / W H and PAR / PW PH) * Content Aspect Ratio (or Content Width and Content Height) * Sample Rate (or Rate and Scale) * Bit
[whatwg] Quality Values for Media Source Elements
Hey all, So, in my first foray into preparing Theora/Vorbis content, for use with video, I realized that I wasn't sure with what settings to encode my materials. Should I: A.) Supply my visitors with the best possible quality at the expense of loading/playback speed for people on slower connections B.) Just account for the lowest common denominator and give everyone a low quality encode or C.) Go halfway and present a medium quality encode acceptable for most people? A. is not legacy-proof, B. is not future-proof, and the C. is neither. C. may sound like the most sensible solution, but even if I were to put up something that worked for most people *right now*, as computers become more capable and connections become faster, more visitors are going to want higher-quality videos, meaning I'd have to stay on top of the relevant trends and update my pages accordingly. Ideally, I would like to be able to simply encode a few different quality variations of the same file and serve each version to its corresponding audience. There are a few ways I could do this. One of the most obvious ways would be to present different versions of the site, e.g. one for slow connections and one for fast connections and have the user pick via a splash page before entering, as was popular in '90s. But this is almost certainly a faux pas today: it puts a wall between the user and my content, and requires me to maintain two different versions of the site. Hardly efficient. Another way would be to itemize each version of the file in a list, with details next to them such as frame and file size, so the user could pick accordingly. While this would probably be fine for downloads, it completely defeats the point of embedded media. Alternatively, I could devise a script that prompts users for their connection speed and/or quality preference, which (assuming they know it) would then go through the available resources on the server and return the version of the file I'd have allocated to that particular response. But that would require either branching for every file alternative of every video on my site in the script—or specifying the quality in some other way that can be programmatically exploited; perhaps using microdata, but then I'd be stuffing the fallback content with name-value pairs, which isn't particularly accessible. Or, I could invent my own HTTP header and try to get everyone to use it. Which is a lot to do for something like this, and isn't guaranteed to work. None of these options seem particularly viable to me. Right now, the HTML5 spec allows UAs to choose between multiple versions of a media resource based on type. In the interest of making media more accessible to users of varying bandwidth and processing power, and easier to maintain for authors, I propose allowing the relative quality of each resource to be specified for multiple-source media. You will notice that in Flash animations, there is a context menu option to change the rendered quality between High, Medium, and Low. Each setting degrades or upgrades the picture, and requires less or more computing power to process respectively. Additionally, some Flash video authors elect to construct their own quality selection UI/scripting within the video itself, allowing them to have a finer degree of control over the presentation of the image. Similarly, YouTube has the ability to switch between standard quality, high quality, and high definition videos based on users' preferences. In the Playback Setup section of Account Settings, you will find the following options: Video Playback Quality Choose the default setting for viewing videos * Choose my video quality dynamically based on the current connection speed. * I have a slow connection. Never play higher-quality video. * I have a fast connection. Always play higher-quality video when it's available. If HTML video is to compete with Flash, or become implemented on as wide a scale as YouTube http://www.youtube.com/html5, it makes sense to allow for some sort of quality choice mechanism, as users will have come to expect that functionality. This could be done by allowing an attribute on source elements that takes a relative value, such as (or similar to) those specified in HTTP http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.9. This attribute could be called quality or qvalue or just q (my personal preference would be it that order decreasing), and be used as such: video controls source src='video-hd.ogv' quality='1.0' type='video/ogg; codecs=theora, vorbis' source src='video-hq.ogv' quality='0.5' type='video/ogg; codecs=theora, vorbis' source src='video-sd.ogv' type='video/ogg; codecs=theora, vorbis' /video In this case, video-hd.ogv (a high definition encode) would be the author's preferred version, video-hq.ogv (a high quality standard definition encode) would be less preferred than video-hd.ogv, but more preferred than video-sd, and video-sd (a standard definition encode) would be
Re: [whatwg] Use cases for the time element
I concur 100%. Additionally, I don't understand why the time element is allowed to specify an arbitrary hour, but not an arbitrary month or year. My own use case involves marking up years of publication for documents I have created, to be displayed in an online resume that can be sorted by date. I do not necessarily have the original timestamps for every file, yet I can recall the years in which they were published. In this case, the year 2005, for instance, is semantically distinct from the numeral 2005, and though the difference can be inferred from context by a human it can not by a machine, hence why things like time2005/time, or time datetime=20054 years ago/time would be useful here. But under the current specification, these uses are invalid, meaning I'd only be able to specify exact dates with meaningful language, as in time datetime=2005-01-012005/time, and hack around it for inexact dates with non-semantics like span class=datetime2005/span. This use case (which has nothing to do with calendars) would certainly not be unique to me, as I'm sure there are many events well-within the Gregorian calendar that have inexact dates, such as the dates of deceased family members for whom incomplete records were kept during the time of their death http://people.mnhs.org/dci/faq.cfm#17. Rather than just presented textually, the results could be marked up in HTML and extracted using an API, browser add-on, or other software that reads the metadata and returns something useful to the user, such as an automatically-generated genealogical entry file that can be imported into a family tree program—much in the way the Operator Toolbar extension for Firefox currently reads hCards and automatically generates contact entry files that can be imported into e-mail programs. The way I see it, if we can mark up abbreviations without having to expand them fully, or even at all (abbrXSLT/abbr, abbr title=XSL TransformationsXSLT/abbr, and abbr title=eXtensible Stylesheet Language TransformationsXSLT/abbr, or even abbr title=catXSLT/abbr are all valid) we should be able to mark up datetimes without having to expand them fully. But don't take my word for it. I'm sure these articles have been mentioned here before, but Eric Meyer http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/ and PPK http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html have also voiced support for a less-restrictive time (Hixie has at least seen the former http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378, though there was no further discussion with him about the issue there.) If these issues have already been discussed, please point me in the right direction so that I can better understand the decision to phrase the spec this way. Thank you, Hugh On Sat, Nov 28, 2009 at 7:11 AM, Jeremy Keith jer...@adactio.com wrote: We seem to be straying behind the bikeshed a little bit here. My point wasn't to point out problems with the examples given in common idioms without dedicated elements http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations The real problem is the definition of the time element itself: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element This sentence: This element is intended as a way to encode modern dates and times in a machine-readable way so that user agents can offer to add them to the user's calendar. ...should be changed to: This element is intended as a way to encode modern dates and times in a machine-readable way. The overly-restrictive clause at the end canonises a single use case as the only usage of the element. The fact that there examples elsewhere in the spec that contradict this definition highlights the problem, but the issue isn't with those examples; it's with the definition of time. HTH, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Use cases for the time element
On Thu, Dec 10, 2009 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Are you planning on using the information in time to *do* the sorting? That is, when someone chooses sort by date, do you have scripting that searches in each section for a time and extracts the date to determine where in the order it should go? Yes, ideally I would like to store all of my data as XHTML+XML. Though I suppose I could describe that data with an arbitrary vocabulary server-side, sort on that, and transform the result into HTML, it makes the script much smaller and easier to write if there's a common syntax in place. Fairness isn't a justification for putting anything in the spec, fortunately. Each piece of the spec has to justify itself. It just seems to me that *requiring* this sort of specificity (rather than simply allowing it) is contrary to the typically rather permissive nature of HTML. If we don't even need to close our tags, why do we need to specify whole dates? As far as I know, there hasn't ever been an element that made validation fail because of a malformed microsyntax; why start now? ISO 8601 (which has been footnoted by the W3C since 1997) allows for several levels of granularity, up to the year. What is it that necessitates this particular level of granularity (aside from adding dates to calendars, which is only one use case)? I agree with Meyer on the first one. That's a useful case. In addition, time's usefulness in Microdata is somewhat impaired by its inability to mark up months or years. These are by far the most common 'fuzzy dates' that one would have to mark up for embedded metadata. Their lack means that vocabularies need to structure themselves to take two dates per real 'date', to allow such fuzziness, which means that date *ranges* would need *four* dates specified. That's just silly. I agree. However, the second one isn't quite an argument for expanding time. It's an outlining of, *if* we decide that we want time to be useful for *all* dates, how we should go about doing it. ppk recognizes that such an approach may not be what the spec wants. I realize that, but the fact that he was able to write that much on the topic just strengthens the argument that time has far more use cases than it's been allotted, and as such, its current definition needs to be addressed, be it in that capacity or smaller.
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 7:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The @caption proposal isn't for an attribute on p only, but rather for an attribute on any element that is a child of a figure. (It's just that most of the time using a p is most appropriate.) Ah, OK. Well, given the circumstances, this does seem like the best approach, though I feel conditionally allowing certain attributes depending on an element's context is a step in the wrong direction. It's confusing given the way HTML will have worked up until that point; as a document author, although I expect elements themselves only to be allowed in certain contexts, I also expect them to carry all of their attributes with them when they are; i.e., attributes are perceived as belonging to the element within which they are set, not the parent of that element. Most of us agree that a more semantic element would be ideal here, yet we can't use one [yet] because of current technical limitations. That sounds like the very situation microformats was created to address. What if we used @itemprop as a placeholder for a future figure-caption element? To make things less verbose, figure could have an implied @itemscope and @itemtype unless specifically overwritten by the author. Ex: figure img src=figure.gif alt=graph p itemprop=captionThe findings/p /figure On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak m...@apple.com wrote: It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. Is this issue being addressed by the latest DOM specification? It seems there should really be a standard behavior for browsers when encountering unknown or unexpected elements that ensures that the next version of HTML is not similarly encumbered by this.
Re: [whatwg] figureimg* caption
Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward.
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 6:33 PM, David Workman workm...@gmail.com wrote: I don't know about others, but that just looks ugly to me (the repetition of 'cite' looks unnecessary). I know elegance isn't crucial, but given the choice between cite for= and cite cite= I'd go for the former. As a possibility though, cite could have a 'for' attribute in the same manner as a label and also support a 'src' attribute to link the element to the original source, giving: cite for=aside-id src=uri What browsers do with the src attribute can be decided later, but it could easily be used as a more semantically meaningful a tag where appropriate. Well, I don't exactly mind the repetition of cite, though @for is probably better as it's an existing attribute and already serves the same purpose. @src, however, should really only be used for replaced content. It does not mean source in the sense of attribution, but in the sense of derivation. I like the idea but I'd go for @href instead, e.g.: pAs cite for=gettysburg href=http://www.whitehouse.gov/about/presidents/abrahamlincoln/;Abraham Lincoln/cite said, q id=gettsyburgFour score and seven years ago .../q/p pcite href=http://www.imdb.com/title/tt0800080/;The Incredible Hulk/cite (2008) is a reboot of cite href=http://www.imdb.com/title/tt0286716/;Hulk/cite (2003)./p @href creates an explicit link to the work or author being cited (whereas a creates an arbitrary one). Whether this is displayed as a traditional hyperlink or merely as a more info context menu, etc. should be up to the UA. If it is rendered as a link though, surrounding links should probably take precedence, i.e.: a href=http://en.wikipedia.org/wiki/Abraham_Lincoln;cite href=http://www.whitehouse.gov/about/presidents/abrahamlincoln/;Abraham Lincoln/cite/a ...would point to Wikipedia, and not the White House. I'm not exactly sure that @for belongs on cite though, as the relationship of author-to-quote is more often one-to-many than one-to-one. It would be cumbersome and redundant for document authors to have to specify the name every time in full just to create an explicit association between the two. For instance, in a list of famous quotes by Abraham Lincoln: ul li q id=gettsyburgFour score and seven years ago .../q --cite for=gettysburg href=http://www.whitehouse.gov/about/presidents/abrahamlincoln/;Abraham Lincoln/cite /li li q id=foolBetter to remain silent and be thought a fool than to speak out and remove all doubt./q --cite for=foolAbraham Lincoln/cite /li /ul is not as efficient as: h1List of Quotes by cite id=abe-lincolnAbraham Lincoln/cite/h1 ul li q id=gettsyburg for=abe-lincolnFour score and seven years ago .../q /li li q id=fool for=abe-lincolnBetter to remain silent and be thought a fool than to speak out and remove all doubt./q /li /ul Dialogs would also benefit from this, as in: cite id=petePete/cite: q for=peteI'm joining a gang./q cite id=meredithMeredith/cite: q for=meredithYou can't!/q citePete/cite: q for=peteDon't try to stop me./q Of course the downside to that is being unable to create a relationship between all of a speaker's quotes and attributions without inventing superfluous @ids. For that I propose an alias attribute for cite which allows it to represent another instance of that same attribution: cite id=petePete/cite: q for=peteI'm joining a gang./q cite id=meredithMeredith/cite: q for=meredithYou can't!/q cite alias=petePete/cite: q for=peteYou can't stop me./q which would also be useful in the informal abbreviation of titles of works: h1cite id=borat href=http://www.imdb.com/title/tt0443453/;Borat: Cultural Learnings of America for Make Benefit Glorious Nation of Kazakhstan/cite (2006)/h1 h2My Review/h2 pcite alias=boratBorat/cite is a hilarious film about.../p
Re: [whatwg] the cite element
On Wed, Oct 7, 2009 at 6:51 PM, David Workman workm...@gmail.com wrote: I agree that href would be better than src due to the reasons you gave. However, rather than adding a new attribute of alias, could cite instead be given a name attribute that works similar to radio button names in forms to group them together? So you would have: cite name=petePeter/cite cite name=meredithMeredith/cite cite name=petePeter/cite and the two citations of Peter are linked together by a common name and in the spec, all cite elements with the same name in a document should have the same content and be referring to the same citable source. That sounds reasonable.
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 4:15 PM, Erik Vorhes e...@textivism.com wrote: I suppose a allows for more functionality in current UAs, but this is an interesting proposition, especially if there were a way to crosslink cite used in this way to the original source (or whatever it would point to). Would it be something along the lines of cite for=aside-id, or did you have something else in mind? How about cite cite=uri, as it would have been in XHTML 2?
