Re: [whatwg] The pic element
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. 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. 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 (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. An `img` element can be used in place of any `source`. `width`/`height` defines size to display selected image at, but does not take part in selection of alternatives. If you could take the alt-text into pic and source I fully'll agree. You should be able to specify an alt-tag for every source if needed (in most use cases it isn't but in some it is if you have another crop with same meaning but different contents) Alt is not supposed to be description of the image. It's supposed to be alternative content to be used instead. e.g. not red triangle with exclamation mark but warning! So different alternative for each source would imply that purpose/meaning of the content changes with viewport size, and that'd be weird — content read to the user would change based on size of the window that a screen reader user may not even see? The common syntax for use with JS polyfills is expected to be: pic src=…noscriptimg src=… alt=…/noscript/pic ##In formal terms The `pic` element requires closing tag. The content is interpreted as a fallback for UAs that don't support `pic` or don't display the image (fallback includes text in img alt inside pic). I wouldn't necessary require a closing tag if you use the short syntax because the alt-text should be in attribute. Void element is not an option due to backwards compatibility. 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. * `media` — same as `media` part in `pic src` * `resolution` — same as `resolution` part in `pic src` * `src` — single URL without escaping or microsyntax * `width` and `height` — analogous to `img width/height` for each alternative image * alt * title are missing IMO. title is global, so available for pic too. Might be worthwhile to specify how title on source behaves. As I've mentioned earlier I think it's not
Re: [whatwg] The pic element
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
Re: [whatwg] The pic element
On Fri, Jun 1, 2012 at 3:05 PM, whatwg-requ...@lists.whatwg.org wrote: 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. 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. Cheers, Aaron Aaron Gustafson @aaronGustafson
[whatwg] Fullscreen events dispatched to elements
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. The Fullscreen specification calls for events to be dispatched to the document, but the WebKit implementation dispatches fullscreenchange and fullscreenerror events to the context element (and they bubble to the document). IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? There is a related thread started on May 11th 2011 by Jer Noble where he proposes dispatching to the elements, but the thread moves onto other topics. I don't see a resolution regarding dispatching to elements other than early general approval by Robert O'Callahan. [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [whatwg] Request for new DOM property textarea.selectionText
Context: I've added setRangeText(newText); // replace selection with newText setRangeText(newText, start, end); // replace given range with newText setRangeText(newText, start, end, action); // see below ...where action is one of: 'select': selects the new text 'start': selects empty range at start of new text 'end': selects empty range at end of new text 'preserve': (default) On Sat, 28 Apr 2012, Maciej Stachowiak wrote: [regarding using execCommand() instead] Does this work in any non-WebKit browsers? (Asking mainly out of curiosity; I would tend to agree in any case that adding nontrivial editing APIs that are specific to only plaintext editable controls is not a good idea. But it might be nice to specify explicitly whether execCommand works on form controls.) While I would not go out of my way to praise execCommand, setRangeText is also not a very good API design: 1) setRangeText is a vague and confusing name. If its only function was replacing the selection, then replaceSelection would be much better, but: 2) The method is overloaded to do a variety of tangentially related things. The overloading makes it hard to give it a good name. If the different operations were different methods, it would be easier to name it well (replaceSelection, replaceRange), but it's hard to describe all four of the selection modes. 3) It's not clear that all of the different selection modes of this function have use cases. The method was directly based on the use cases presented by authors earlier in this thread. It's basically two things: changing the selected text, and changing a specific (not necessarily selected) part of the text, without changing the selection. We could indeed have setSelectionText(newText) setRangeText(newText, start, end, action) ...but I'm not sure that's really better. On Sun, 29 Apr 2012, Aryeh Gregor wrote: 3) It's not clear that all of the different selection modes of this function have use cases. In particular, the fourth argument's effect seems trivial to replicate using .selectionStart and .selectionEnd, so why is it worth the extra API surface area? It's trivial in that it's not complicated, but it's nonetheless a pain in the neck. That's what the original complaint was about. On Sun, 29 Apr 2012, Ryosuke Niwa wrote: In this case, we have an API, namely document.execCommand, supported by two major browser engines (for years) that provides more or less the same functionality as the proposed API. I really don't think it makes sense to use execCommand() with text fields. It's the contenteditable API. I think we should move towards having it just work for contenteditable, not move towards having it work in text fields as well. On Mon, 30 Apr 2012, Ryosuke Niwa wrote: On Mon, Apr 30, 2012 at 10:41 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai o...@chromium.org wrote: This looks good to me. Could we just call the method setText though since the range values are optional. setRangeText, in retrospect, is wordy and confusing in a way that setText isn't IMO. .setText(foo) sounds like it should set the entire text, not just the selected text. I think the problem is that it automatically uses selectionStart selectionEnd when offsets are not supplied. The semantics would have been much clearer if offsets were not optional. I'd argue that we should either disallow setText without offsets, or setText should use 0 and the length of the text field instead of selectionStart and selectionEnd respectively when offsets are omitted. Replacing the selected text was one of the main use cases leading to 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 2/06/2012 11:19 a.m., Vincent Scheib wrote: IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? 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. Because of this, the spec was then changed to dispatch fullscreenchange to the context element on entering fullscreen, and to the document on exit, but we found this inconsistent, since a listener has to listen to multiple nodes to receive both exit and enter events, so the spec was changed again to always dispatch fullscreenchange to the document. Regards, Chris P.
