Re: [whatwg] The pic element
Am 01.06.2012 um 20:24 schrieb Kornel Lesiński: On 1 cze 2012, at 00:58, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: • Improved alternative text — allows structured fallback, avoids duplication. This is where I do not agree. If you use MQ style with source you have a messy markup when writing alternative text inside the pic-element. Since source is not read nor displayed, it doesn't matter. You can simply treat entire content as fallback. Sure but why? It is much more clearly to use the alt-attribute than using text between container and child elements IMO. Alt-text should always be in an attribute and this would also be easier for screenreaders etc. Structure is there to aid screen readers. See http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0216.html pic src=portrait.jpg (orientation:portrait), landscape.jpgalt text/pic Selects image based on orientation of the device. Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. It is noisier of course but also clearer. I think this is a matter of personal preference. Embeds image at 192dpi (default scaling is 2x, possible to override with CSS). Same as `pic src=image.jpg 2xalt text/pic` or `img src=100x100px width=50 height=50 alt=alt text`. Why is default scaling 2x? A default image should always be @1x, right? We already have element for 1x images – img In the future 1x displays will be low-end minority and 2x will be the norm. It'll be annoying for designers that the default looks terribly and every page always needs the bad default overridden. I'm trying to avoid need for yet another opt-out from the past like doctype and meta charset. It'd be great if in 10-20 years all you had to do is type pic src instead of img src to get first-class support for hires images. To address Tab's concern the default is connected to image-resolution in CSS, so you can change it if you need to: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html Yes but won't we at least dimiss img from our new code? I thought img is only the fallback… And then we should always serve the minimum resolution first. Regardless which resolution this minimal file has, it should be the @1x IMO. Or am I missing something? (I'm not sure if `source` should allow microsyntax in `src` `source src=b 3x` instead of `resolution=3x`) I don't think so. It is much easier to have separate attributes. But what about extending the media-attr so we can write: source src=b media=3x Resolution descriptor is not a media query. I'd like to make that clear — it's not merely an abbreviation of min-device-pixel-ratio, it's a property of the image — more similar to width/height attributes. Fair enough :-) After thinking a bit about it it sounds better this way. Cheers, Anselm
Re: [whatwg] The pic element
Am 01.06.2012 um 21:01 schrieb Julian Reschke: On 2012-06-01 20:24, Kornel Lesiński wrote: ... If there are commas or backslashes in the URL they must be escaped with `\`. This is another problem why I would separate the diff. srces. Escaping an URL is not something that should be necessary in HTML I think. I agree, it's ugly, but otherwise you get ambiguous syntax for entries without descriptor or media query. I thought about specifying some magic, like ignoring trailing comma in URL, but all such magical solutions have surprising edge cases. Explicit escaping is at least easy to comprehend. ... An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. Best regards, Julian I also would like to see another delimiting syntax which is clearer. What about JSON-syntax or just | ? I mean a backslash is not that common in a URL but commas are more and more and you all know that escaping is no fun. So we should really try to avoid this. -Anselm
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 01:05:23 -0500, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. I also would like to see another delimiting syntax which is clearer. What about JSON-syntax or just | ? I mean a backslash is not that common in a URL but commas are more and more and you all know that escaping is no fun. So we should really try to avoid this. Another character could work in theory, but I wonder whether it would work in practice. For example meta name=viewport was documented to support only comma, but thanks to silent error recovery authors ended up using and relying on semicolon: http://lists.w3.org/Archives/Public/www-style/2011Oct/0652.html I wonder whether reverse of it could happen with list of sources, e.g. unexpected comma parsed as invalid media query could end up delimiting sources in some implementations, and then we'll end up with worst of both worlds (both ambiguous comma and other unintuitive delimiter needed for web-compat). -- regards, Kornel Lesiński
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 00:56:55 -0500, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. I’m still digesting the overall proposal, but regarding the media-* and src-* attributes, my main concern would be limiting ourselves by prescribing a set number of sizes (e.g. small, medium, and large) when in reality there may be more nuance in art direction than that. might accommodate. That is only partially true because this is just a proposal by me which can easily be changed to another not limiting syntax… But nevertheless you might not have more than 9 different file-sizes, right? This is what is covered by mine (xxxs, xxs, xs, s, m, l, xl, xxl, xxxl). I initially presumed that any name could be used, similarly to data-*, e.g. src-foobar= media-foobar=. However, that doesn't imply any ordering (attributes don't have order by definition), and that complicates source selection algorithm. In that case I think the syntax with separated attributes is less clear than a microsyntax in a single attribute — list in a single attribute has obvious ordering and doesn't rely on an ordered set of predefined names. -- regards, Kornel Lesiński
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 01:02:55 -0500, Anselm Hannemann Web Development
i...@anselm-hannemann.com wrote:
• Improved alternative text — allows structured fallback, avoids
duplication.
This is where I do not agree. If you use MQ style with source you
have a messy markup when writing alternative text inside the
pic-element.
Since source is not read nor displayed, it doesn't matter. You can
simply treat entire content as fallback.
Sure but why? It is much more clearly to use the alt-attribute than
using text between container and child elements IMO.
object, iframe and canvas use content as a fallback. XHTML2 was
supposed to use this fallback model for all elements (global src). It
seems that img alt was just a mistake made in early development of HTML.
Since it's impossible to introduce void element at this point (XML and DTD
boats have sailed …or sunk) we'll have to have /pic anyway. At least we
can make the best of it and use it for rich fallback that wasn't possible
with img before, and which is harder to ignore than an attribute,
because the parser will require /pic.
I'm trying to avoid need for yet another opt-out from the past like
doctype and meta charset.
It'd be great if in 10-20 years all you had to do is type pic src
instead of img src to get first-class support for hires images.
To address Tab's concern the default is connected to image-resolution
in CSS, so you can change it if you need to:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html
Yes but won't we at least dimiss img from our new code? I thought img is
only the fallback…
And then we should always serve the minimum resolution first.
Regardless which resolution this minimal file has, it should be the @1x
IMO.
Or am I missing something?
Yes, img is the fallback until all UAs start supporting the new element.
I'm not sure what do you mean by we should always serve the minimum
resolution first. If alternatives are offered to the UA, IMHO it should
be up to UA whether it downloads low-res first or only high-res image.
I'm afraid that when high-dpi displays become the norm the minimal useful
HTML template will grow to be something like:
!DOCTYPE html
meta charset=UTF-8
stylehtml {image-resolution:2dppx}/style
and I'm trying to find a way to avoid having all authors add yet another
boilerplate opt-in.
I don't know what to do with default-lowres background-image, so maybe
this is an unavoidable problem :(
--
regards, Kornel Lesiński
Re: [whatwg] The pic element
On Mon, 04 Jun 2012 09:58:52 +0200, Kornel Lesiński kor...@geekhood.net wrote: Since it's impossible to introduce void element at this point It's not impossible, but we generally try to only do it when there's a container (like video) so it gets popped off the stack soon enough to not break the whole page in old browsers. However, when we *want* fallback, we *should* use a non-void element, because using the content as fallback is better than using an attribute as fallback: * It actually gets rendered in old browsers instead of getting ignored. * It supports rich markup (which enables e.g. tagging multiple languages, bidi, ruby, etc). canvas was originally implemented as a void element in Safari, but was specced as as non-void element for the above reasons. -- Simon Pieters Opera Software
[whatwg] Interaction between img srcset and CSS image-resolution
Hi How do img srcset and CSS image-resolution interact? What happens with e.g. img srcset=foo.jpg 2x style=image-resolution:2dppx? -- Simon Pieters Opera Software
Re: [whatwg] The pic element
On 2012-06-04 09:32, Kornel Lesiński wrote: On Mon, 04 Jun 2012 01:05:23 -0500, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: An alternative is to pick different delimiters. See, for instance, http://tools.ietf.org/html/rfc2295#section-8.3. I also would like to see another delimiting syntax which is clearer. What about JSON-syntax or just | ? I mean a backslash is not that common in a URL but commas are more and more and you all know that escaping is no fun. So we should really try to avoid this. Another character could work in theory, but I wonder whether it would work in practice. For example meta name=viewport was documented to support only comma, but thanks to silent error recovery authors ended up using and relying on semicolon: http://lists.w3.org/Archives/Public/www-style/2011Oct/0652.html I wonder whether reverse of it could happen with list of sources, e.g. unexpected comma parsed as invalid media query could end up delimiting sources in some implementations, and then we'll end up with worst of both worlds (both ambiguous comma and other unintuitive delimiter needed for web-compat). 1) Use a format where the delimiter is always the same, (2) where escaping never is needed, and (3) specify the parser to ignore all malformed attribute values. Best regards, Julian
Re: [whatwg] was The pic element, now about alt text
On Jun 3, 2012, at 23:02 , Anselm Hannemann Web Development wrote: Sure but why? It is much more clearly to use the alt-attribute than using text between container and child elements IMO. Alt-text should always be in an attribute and this would also be easier for screenreaders etc. This may be an aside to the current discussion, but actually I think that user-presentable text should *never* be in an attribute. Why? 1) 'ML' stands for markup language; what's in the markup should be information about the content, not the content itself. 2) More important, when text is in an attribute, it's not amenable to markup. You want to style the alt text, or associate it with a CSS class, or tag it with a language, script, or writing direction, or…? It needs to be in the content, and then that's all possible. I realize that changing where alt text is for existing elements would be…problematic…but I don't think we should propagate the error further. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] was The pic element, now about alt text
On Monday, June 04, 2012 1:30 PM David Singer wrote This may be an aside to the current discussion, but actually I think that user-presentable text should *never* be in an attribute. Why? 1) 'ML' stands for markup language; what's in the markup should be information about the content, not the content itself. 2) More important, when text is in an attribute, it's not amenable to markup. You want to style the alt text, or associate it with a CSS class, or tag it with a language, script, or writing direction, or.? It needs to be in the content, and then that's all possible. I realize that changing where alt text is for existing elements would be.problematic.but I don't think we should propagate the error further. - This thinking seems very valid to me. By extension, when the semantics of the language is geometry, as in SVG, then relegating that content to CSS rather than the DOM would be even a tad worse than injecting it into attributes. Actual nodes seem to be where the meaningful nouns of a language should be with attributes being for adjectives and styles for adverbs. The verbs are, by this metaphor, behaviors as revealed through script or declarative constructs. Cheers DD
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. -Jer
Re: [whatwg] MediaController feedback
On Wed, 2 Nov 2011, Jer Noble wrote: I'm currently working on implementing MediaController in WebKit https://bugs.webkit.org/show_bug.cgi?id=71341, and have a couple pieces of feedback from an implementor's POV: * MediaController Playback State and Ready State The spec defines both a most recently reported readiness state[1] and a most recently reported playback state[2] which, when changed, trigger a variety of event. Because these previous values of these states must be compared each time they are recomputed[3], we must store these values in our MediaController implementation, which is no huge burdon. However, when I was writing testcases for my implementation, I noticed that there was no way to query the current value of either the playback state or the ready state, as neither was present in the IDL for MediaController. This makes writing test cases much more difficult, as they now much rely on waiting for edge-triggered events. In addition, there is a use case for having playbackState and readyState in the MediaController IDL. When adding a MediaController to an HTMLMediaElement, the spec does not require the media controller to report the controller state. (It does require that the MediaController bring the media element up to speed with the new controller.) In this case, the media controller should also be requried to report the controller state, as adding a blocking media element to a controller should probably cause the playbackState to revert to WAITING. But if the current playbackState is already WAITING, no waiting event will be emitted, and the client waiting on such an event will wait forever. I've updated to report the controller state. Actually exposing the controller state is not as trivial as it may first appear, in particular if we want to maintain the synchronous illusion (i.e. only change the state as the events fire, not before). But I've done that too. * MediaController.play() The MediaController play() function does not actually cause its slaved media elements to play. If all the slaved media elements are paused, the MediaController is a blocked media controller, and none will play until at least one element has play() called on it directly. And even in that case, only the playing elements will begin playing. In addition, the user interface section of the spec says the following: When a media element has a current media controller, and all the slaved media elements of that MediaController are paused, the user agent should unpause all the slaved media elements when the user invokes a user agent interface control for beginning playback. So now, an individual media control must be able to access all other HTMLMediaElements associated with a given MediaController, because there is no facility in MediaController to actually unpause all the slaved media elements. In a previous paragraph in that same section: When a media element has a current media controller, the user agent's user interface for pausing and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, and for muting or changing the volume of audio of the entire group must be implemented in terms of the MediaController API exposed on that current media controller. Except, in the case of unpausing, this extra requirement of unpausing the slaved media elements is somewhat in conflict with this paragraph. I tried to fix this. I would like to propose three changes to the spec: + Modify the section bring the media element up to speed with the new controller[5] to require that a media element added to a playing media controller must begin playing, and one added to a paused media controller must pause. + Modiy the section controller . play()[6] to require that the user agent unpause all the slaved media elements. + Modify the section controller . pause()[7] to require that the user egent pause all the slaved media elements. + Remove the section from user interface[8] which requires the user agent unpause all the slaved media elements, quoted above. I don't really understand this proposal. Could you elaborate on this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 4, 2012, at 10:43 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? As it is a holdover from when we implemented the Mozilla Full Screen API proposal[1], which required that behavior, no. -Jer [1] https://wiki.mozilla.org/Gecko:FullScreenAPI#fullscreenchange_event
