Re: [whatwg] The src-N proposal
Am 20.11.2013 06:24 schrieb Bruno Racineux: On 11/19/13 12:12 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 19 Nov 2013, Markus Ernst wrote: I can't recall the reasons why Florian's proposal of combining picture and @srcset fell out of the discussion. To me it still looks like the most useable draft so far. I responsed to proposals along those lines last year: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.htm l Search for multi-element for the specific response to proposals that involve multiple elements. There are other concerns against any non-centralized approaches like picture. [...] Any author used to the flexibility of css shouldn't have the burden to deal with hard-coded unalterable stuff like that. It's as bad as an inline css-style to deal with. I do totally agree with you. AFAICS, all proposals with a significant amount of support (picture, srcset, src-N) share this problem. I don't have the impression that adding centralization has much support right now. Anyway, once there is a consent about the respImg syntax, it may be easier to propose a centralisation mechanism at the CSS side, e.g. some variable or constant useable in the MQ.
Re: [whatwg] picture redux
Am 20.11.2013 22:27 schrieb Tab Atkins Jr.:
On Wed, Nov 20, 2013 at 9:25 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Simon Pieters wrote up Kornel's earlier approach to a saner, more
palatable source selection algorithm for picture (rather than
copying video/audio). This approach also has a new wrinkle:
picture *requires* an img child, and it's the img that still
actually displays the image. The picture element is just a wrapper
for the img+source elements, and provides a context for the source
selection algorithm. This makes testing substantially easier, as we
can limit ourselves to testing the source selection algorithm, and
probably makes implementation easier as well.
Adam Barth brings up a wrinkle on blink-dev, based on an older
objection he had to picture.
At that time, Blink was considering moving its preload scanner
off-main-thread, and Adam wanted to make sure that the design of
picture didn't preclude that from happening. Now, our preload
scanner *is* on a separate thread, so we're definitely constrained in
what we can do there.
His basic concern is that MQs are too complex to be done
off-main-thread, so it's hard/impossible to do MQs in the preload
scanner.
My response is that *some* MQs are perfectly fine to do off-thread, as
they're basically just static properties of the display. John Mellor,
who's done some preliminary work around this in Blink, supports this.
We can just hand the relevant data to the preload scanner and do
simple MQ parsing.
We don't need to actually limit the MQs which are allowed in
picture. The preloader is just an optimization in the first place;
we *want* the image to be preloaded, but if it isn't, the image will
still work, just slower. We can provide a note about which types of
MQs are likely to be recognized by the preloader. Unrecognized MQs
can just cause the preloader to ignore that source, and if that
means an incorrect source is selected, that's just a wasted download,
but back on the main thread, the source selection algorithm will pick
the right picture a little bit later.
Regardless of how we do this, though, *some* form of MQ or MQ-like
functionality is part of *every* proposal that has been brought
forward, as it's necessary for resolving several of the use-cases.
I am still very much concerned about centralizing MQs, and - without
knowledge about the preload scanner - I just wondered whether
centralization could be beneficial for the preload scanner, too. If we
had some kind of CSS constants available, this could look somehow like
(adapting the constant syntax suggested by fantasai years ago, just for
the sake of illustration):
head
style type=text/css
@define mediaqueries {
small: (max-width:479.99px);
medium: (min-width:480px) and (max-width:999.99px);
large: (min-width:1000px)
}
/style
/head
...
source media=small src=small.jpg 1x, small2.jpg 2x
...
Like this, MQs could be evaluated before the preload scanner is started,
I assume?
I am aware of the facts that the CSS aspects will have to be suggested
in the CSS WG list, and that no CSS constants are available so far. But
it would be nice if the respImg spec would be the way that it will
support centralized MQs, once they will be possible from the CSS side.
Thus my suggestion for the spec of the @media attribute in source: It
must contain a media query, or a value that represents the result of an
evaluated media query.
Re: [whatwg] picture redux
Something that just came to my mind: Unlike srcset and src-N, picture has the power to support MQs beyond viewport width: picture source media=screen src=... source media=print src=... img src=... /picture The UA will have to download both sources, or printing will be delayed. Is this a problem?
Re: [whatwg] The src-N proposal
Am 19.11.2013 08:49 schrieb Yoav Weiss: If you'd like to further discuss that concern, can you please open up a new thread? This one discusses solutions to the responsive images problem use-cases (e.g. src-N, picture, srcset, etc) My personal conclusion of this part of the thread is: The (negative) bandwidth effect caused by the verbosity of the respImg syntax is minimal compared to the (positive) bandwith effect achieved by the actual use of respImgs. Thus, the final solution should be most understandable and easily applicable by average authors (as I am), because otherwise authors will either hesitate to use it, or (even worse) use it incorrectly. This would IMHO speak against both srcset and src-N approaches, and be in favor of some picture-like approach (again), because it is human-understandable and DOM-ready HTML. I am sorry I am not capable of fully understanding all related threads, but as far as I can get it, all technical issues of this approach seem to have been stated to be solveable so far.
Re: [whatwg] The src-N proposal
Am 19.11.2013 12:13 schrieb Markus Ernst: Am 19.11.2013 08:49 schrieb Yoav Weiss: If you'd like to further discuss that concern, can you please open up a new thread? This one discusses solutions to the responsive images problem use-cases (e.g. src-N, picture, srcset, etc) My personal conclusion of this part of the thread is: The (negative) bandwidth effect caused by the verbosity of the respImg syntax is minimal compared to the (positive) bandwith effect achieved by the actual use of respImgs. Thus, the final solution should be most understandable and easily applicable by average authors (as I am), because otherwise authors will either hesitate to use it, or (even worse) use it incorrectly. This would IMHO speak against both srcset and src-N approaches, and be in favor of some picture-like approach (again), because it is human-understandable and DOM-ready HTML. I am sorry I am not capable of fully understanding all related threads, but as far as I can get it, all technical issues of this approach seem to have been stated to be solveable so far. May I humbly point back to http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036173.html I can't recall the reasons why Florian's proposal of combining picture and @srcset fell out of the discussion. To me it still looks like the most useable draft so far.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 13.11.2013 14:52 schrieb John Mellor:
style
@media (max-width: 19.99em) {
.artdirected { content: replaced image-set(128px; attr(srcs-smallicon));
}
}
@media (min-width: 20em) {
.artdirected { content: replaced image-set(100% (30em) 50% (50em) 33%;
attr(srcs-flexwidth)); }
}
/style
...
img class=artdirected src=fallback.jpg
srcs-smallicon=i64.jpg 64, i128.jpg 128, i256.jpg 256
srcs-flexwidth=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg 1280,
2560.jpg 2560
(note that the above is a maximally complex example, incorporating art
direction, viewport-switching and dpr-switching; most normal cases would be
simpler than this)
Looks great to me. Just verbose enough to be understood by average
authors (as I am one), perfectly maintainable, and as powerful as src-N.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 12.11.2013 14:33 schrieb Ryosuke Niwa:
On Nov 12, 2013, at 4:11 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2013-11-12 9:58, Adam Barth wrote:
Unfortunately, we can't add new tags to head. If the parser sees a
tag it doesn't recognize in the head, it creates a fake body tag and
pushes the tag down into the body.
But you could use style type=text/foobar.../style, with a suitable value
for foobar, like x-imgset. This could even be handled with a polyfill in old
browsers (JavaScript code that reads such elements and interprets their
content).
Maybe there's a CSS solution to this problem? Do we just need to make
the preload scanner smarter about interpreting CSS?
In fact, I’d argue that CSS will be a better fit to address art direction use
case since it’s purely presentational.
We could define some ways to list set of images that could be replaced for a
given img element in HTML and then let CSS pick which one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
I assume that in order to allow preloading, some mechanism would have to
be added to tell the UA that this part of the CSS has to be evaluated
before downloading starts.
(I personnally would prefer author-defined keywords instead of numbers
for the identification of sources.)
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of
approach is not part of the discussion?
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 12.11.2013 18:50 schrieb Adam Barth:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
What I don't like about CSS approaches is the fact that changing the
source of an image is fundamentally different from changing a dimension
or color of an element. This is not presentational in the same way.
Having to reference content images in the CSS in order to change their
sources is an authoring nightmare.
If inventing new elements or attributes is bad, I assume the whole
discussion on responsive images is actually obsolete, as what you
suggest can be done already in principle.
Re: [whatwg] Viewing situations - Re: The src-N proposal
Am 10.11.2013 19:48 schrieb Jukka K. Korpela:
2013-11-10 19:36, Markus Ernst wrote:
Having a look at the proposal, and reading the thread especially with
regard to complexity and verbosity, I got the impression that @src-n
shares a main objection with @srcset and picture, that it mixes up
content and design to some extent.
That would be my main concern, too. But I would rather say that it
really mixes up content and presentation, moving to HTML something that
belongs to the scope of styling and can currently be handled in CSS.
That is what I wanted to say - sorry my English is poor sometimes.
Thus I suggest a modified approach which moves the distinction of
viewing situations, or breakpoints, to the head of the document,
creating some variable-like references to be used instead of numbers.
Some kind of src-var instead of src-N. Therefore, a new element for the
head would be necessary; I call it situations, it could also be
breakpoints or whatever is considered more appropriate:
Adding new elements is questionable, especially if they have content
(which would be rendered as-is by current user agents).
I see. So let's use an existing, void element :-)
meta name=situations content=
small: (max-width: 400px),
medium: (max-width: 1000px)
img src-small=pic-small.jpg
src-small2x=pic-medium.jpg
src-medium=pic-medium.jpg
src-medium2x=pic-large.jpg
src-large2x=pic-x-large.jpg
src=pic-large.jpg
alt=Obama talking to a soldier in hospital scrubs.
This, too, would mix content and presentation. Admittedly, the line
between them isn't always crystal clear, even if most of HTML5 pretends
that it is. But here the approach should let an author specify an img
element in markup and separately specify, in a style sheet language,
that in some cases the src attribute value is to be overridden.
If people think that current CSS media queries are inadequate for the
purpose (and I'm not convinced that they are), then the first question
should be whether CSS can be suitably enhanced. Failing that, it would
seem natural to define a new, restricted style language. Something like
this:
style type=text/is
@media(max-width: 400px) { #pic { src: url(pic-small.jpg); } }
...
/style
...
img id=pic src=pic-large.jpg alt=
title=Obama talking to a soldier in hospital scrubs.
That would mean to maintain one or several style declarations per
content image, separated in the style element; looks horrible to me.
The topic we are discussing involves both content and presentation, as
we try to serve different content (image files) when the presentation
changes. As an author, I'd favorite a solution that keeps the content
section as clean, simple and intuitive as possible.
I think that my approach does provide the most simple and intuitive
syntax for the image element, and take all the complicated stuff out
into the head section. This may not be pure separation of content and
presentation, but it sure goes further in that direction than the other
approaches discussed at the time, and it makes maintaining and updating
the content easier than other approaches.
Re: [whatwg] Viewing situations - Re: The src-N proposal
Am 10.11.2013 18:53 schrieb Tab Atkins Jr.: This proposal does not address Variable-Sized Images; handling the difficulty and verbosity of that is indeed centralized to the situations element, but that doesn't make it much better. I omitted variable-sized images indeed. The syntax you propose is very lean and elegant and powerful, but it looks rather unintuitive to me. Many websites are built by highly-skilled professionals, and later maintained by editors with less technical knowledge. They can learn how to export an image in 3 or 5 different sizes, but you can't expect them to apply the correct syntax (nor figure out which values to insert into any future CMS UI to generate the img tag). Also, I am afraid that this shortcut syntax can be quite harmful if applied incorrectly, e.g. by copy-pasting authors. This is why I'd prefer verbosity in this case.
Re: [whatwg] Viewing situations - Re: The src-N proposal
Am 10.11.2013 18:36 schrieb Markus Ernst: Moving the distinction of viewing situations to the head would have some advantages IMO: - Verbosity is centralized, thus has not to be repeated in every img element - The UA does not need to evaluate the same MQs again for every img in the content - In order to achieve a consistent handling of responsivity, the situation variables may be reused in other content elements, such as video, and also in the link element as an alternative to todays @media attribute - Easier handling of redesigns when breakpoints change; no modifications needed in the page content While writing answers to Yucca's and Tab's messages, I got aware of one more interesting point: Many websites are maintained by editors who have no deep knowledge of HTML. They use CMS systems that provide more or less intuitive UIs for content editing. Now, every respImg solution that uses MQs inside the img element will be quite hard to create an useable UI for. In the image selection dialog, it would need to handle an unknown number of sources with the respective MQs. And the editors will need to consult a manual each time they insert an image, to know the values they have to enter for the MQ. OTOH, handling a predefined set of viewing situations could be easily implemented in the image picker of a CMS. Once the system knows the situation variables (by parsing the template's head, or configured in the preferences), it can show a dialog that asks for the exact set of required sources.
Re: [whatwg] Background audio channels
Am 10.04.2013 21:14 schrieb Wesley Johnston: Finally, apps can already solve this problem today - they know when they go into the background (for different permutations of background, as Jer mentioned), and they can pretty trivially mute or pause their playing audio. Most of them don't. Yes err... isn't this my point? Most of them (that I've encountered) aren't not muting themselves because they think what they're playing is so important that it shouldn't be stopped. Well I as a user expect to have control on what is playing and what is muted. If I want to stop the audio or video, I actually hit the stop button or close the tab. If I focus an other tab or window or application without hitting stop or pause, I usually wish to continue listening, while working on something else. To address your issue, UAs might provide a User setting such as Stop audio and video playback when the page/tab is in the background, which may be eventually overridden by hitting play again. What I consider really annoying about user control is, that video players usually have no stop button, but only a pause one, so the user can't stop the download process without closing or reloading the page. But this is another topic. -- Markus
Re: [whatwg] Hide placeholder on input controls on focus
Am 21.03.2013 12:10 schrieb James Ross: Just as an added data-point (that I only noticed today) - Windows 7's placeholder implementation in the Start menu and Explorer's search box: - Focusing the input box with tab/Control-E or autofocus when opening the Start menu does *not* hide the placeholder. - Control-A or clicking in the textbox hides the placeholder. I was not aware of the possibility to distinguish between clicking in a textbox and other ways to focus it. This behaviour seems to be very user-friendly to me.
Re: [whatwg] Hide placeholder on input controls on focus
Am 20.03.2013 02:20 schrieb Kit Grose: In almost every case the placeholder remains visible until the user has begun typing, as I strongly believe it ought to be remain in the specification, since it provides the contextual hint for as long as possible. Do you refer to author implementations via scripting? As in Opera and IE 10, the placeholder gets hidden when the field is focused; thus, regarding browser implementations, the almost every case refers to Firefox, Chrome, and some versions of Safari. That it has historically been implemented in a way that implies selectable content is, I believe, chiefly due to the lack of support for a right way to do this (which has led many developers to implement the placeholder text simply by setting the field's value to the placeholder text as the simplest implementation). The current implementations of Firefox and Chrome seem to imply selectable content at least to some users, as Tim and myself reported in this thread. Both show the placeholder in a lighter color than the input text; this does not seem to fully solve the issue, maybe because many web designers color text in form fields anyway. The problem is that some users do not even start to type when they see text in the field they focused. Thus I strongly believe that some visible hint at the _focusing_ moment would be helpful for these users. If the Opera and IE behaviour of totally hiding the placeholder is considered as suboptimal, the placeholder could be blurred, made semi-transparent or whatever; but I am sure that something should happen when the control gets focus, and not only when the user starts typing.
[whatwg] Hide placeholder on input controls on focus
Hello Whatwg On several occasions I encountered that users got confused by the placeholders on input fields. In a doodle.com survey last week, 2 out of 5 people answered me via e-mail that they were not able to fill in their names in the name field, because they tried to highlight and delete the placeholder saying Your name. Also, some months ago I had phone calls from clients who were desperate because they thought they weren't able to log into their Hotmail accounts anymore, for the same reason (I think Hotmail has made the placeholder highlightable since then). It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible. A short browser comparison shows: - Firefox and Chrome hide the placeholder when the user starts typing - Opera and Safari hide it when the field gets focus - IE I can't test because I haven't IE 10 The Opera and Safari behaviour seems to make sense to me, while the behaviour of Firefox and Chrome causes this kind of annoying confusion. Thus I'd suggest to modify the following sentence in 4.10.7.3.10: User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string or the control is not focused (or both), e.g. by displaying it inside a blank unfocused control and hiding it otherwise. To: ...when the element's value is the empty string _and_ the control is not focused, e.g. by displaying ... Best Regards Markus Ernst
Re: [whatwg] Hide placeholder on input controls on focus
Am 18.03.2013 13:27 schrieb Boris Zbarsky:
On 3/18/13 5:31 AM, Markus Ernst wrote:
- Opera and Safari hide it when the field gets focus
The behavior of Safari here is platform-dependent or possibly
version-dependent. Safari 6 on Mac doesn't hide the placeholder until
you start typing.
...when the element's value is the empty string _and_ the control is not
focused, e.g. by displaying ...
I believe the spec used to say this and got changed. Certainly the
Gecko implementation did this and got changed. It's worth looking into
why the changes were made before simply trying to revert them.
I had searched the list archives for placeholder before posting, but
of course I may have missed the relevant discussion. I did not search
Firefox bugs, though.
A reason for the behaviour of Firefox and Chrome may be that some user
may not have read the placeholder text before focusing the control.
Anyway, if this behavior lets some users think they can't even fill in
the form, there must be something wrong about it. Maybe some implementer
may want to include this case in their usability tests; I do not insist
in discussing it at spec level.
Am 18.03.2013 17:47 schrieb Tim Streater:
I for one find this to be extremely irritating. Workaround I was
given by some kind person:
[placeholder]:focus::-webkit-input-placeholder
{
color: transparent;
}
Yes, from an author's POV I could also imagine scripting solutions to
this case. Anyway it looks like a more general UI question to me.
Re: [whatwg] AllowSeamless feedback
Am 15.01.2013 00:39 schrieb Nasko Oskov: Hi whatwg, I recently became aware of the proposal to add AllowSeamless attribute that will permit cross-origin seamless iframes ( http://wiki.whatwg.org/wiki/AllowSeamless). We are currently working on a new security policy in Chrome, which will separate each site into its own renderer process. More information can be found at http://www.chromium.org/developers/design-documents/site-isolation. Re-reading this Chromium document, I had the idea that AllowSeamless may be a special case of something which should rather be like AllowSameOrigin? A document that allows to be treated as same-origin by the including document would then be removed from the siteInstance (or security context) of its own origin, and added to the one of the including document. I think that per-origin control would be necessary in this case, so it would look somehow like: meta name=allow-same-origin content=foo.net, bar.com Or: html allow-same-origin=foo.net, bar.com html allow-same-origin=all I see the following advantages compared to an AllowSeamless solution: - New spec is only needed for the mechanism itself. All issues that derive from the mechanism are already covered by the same-origin policy. - Authors who decide to use AllowSameOrigin in a resource are more likely to be aware of security risks than they were about an AllowSeamless solution (which actually sounds like something purely design-related) (Excuse me in case this is a silly idea - I am a web author with zero knowledge on browser implementation.)
Re: [whatwg] AllowSeamless feedback
Am 18.01.2013 14:40 schrieb Anne van Kesteren: On Tue, Jan 15, 2013 at 2:44 PM, Markus Ernst derer...@gmx.ch wrote: The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. So, would it be possible to generally treat resources that allow seamless embedding as same-origin from the security POV? No. And AllowSameOrigin would not work either. Because of scripting one resource granting such access means exposing the entire origin to attacks. I did not mean to merge origins, but to completely detach the included resource from its origin, and allocate it to the origin of the including document: - Document from A domain-A.com includes resource B from domain-B.com - Resource B has set AllowSameOrigin=domain-A.com - Document A and resource B can access each other as same-origin - Now Resource B tries to access resource C from domain-B.com - Resource C does not have AllowSameOrigin specified for domain-A.com - Resource B cannot access resource C, as it would violate the same-origin policy. Resource B is treated as of origin domain-A.com. I don't know whether this is possible, but I think if yes, it would be an elegant solution to this topic.
Re: [whatwg] AllowSeamless feedback
Am 15.01.2013 01:36 schrieb Nasko Oskov: On Mon, Jan 14, 2013 at 3:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 15, 2013 at 12:39 AM, Nasko Oskov na...@chromium.org wrote: Based on the existing security concerns listed in the proposal and the fact that it might prevent a useful new security architecture in browsers, I would suggest this not be added to the web platform. FWIW, I think that limitation is known. (At least I cannot remember the last time someone actually proposed new API surface requiring synchronous access between two cross-origin Window objects.) iframe seamless could still be useful however cross-origin, even without cross-boundary events. The input events was just one example. There are other cases where having an asynchronous boundary can lead to unexpected behavior for developers. [...] It's not clear whether implementing these asynchronously will lead to a good experience. The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. So, would it be possible to generally treat resources that allow seamless embedding as same-origin from the security POV? (It would be a real pity if a useful security architecture would prevent a useful inclusion mechanism, and vice versa.)
Re: [whatwg] Sortable Tables
Am 28.12.2012 03:04 schrieb Ian Hickson:
I've added a feature to HTML to enable users (and authors) to sort tables.
The basic design of the feature is that if a column's th has a sorted=
attribute, the UA will sort the table every time the mutation observers
would fire (before they fire). A table can have a sortable= attribute,
which lets the user tell the user agent to add sorted= attributes to
columns to sort them.
This spec is great work! Anyway I have some thoughts on user sorting and
the sort() method - if they are silly, please feel free to ignore them.
I believe that asc and desc would be more intuitive to handle than
and reverse, and I think that some kind of th.sortedState attribute
would be handy, to question the actual state of the table.
Given a basic table such as:
table id=pirates
thead
tr
th sorted=1 id=lastLast name/th
th sorted=2 id=firstFirst name/th
th sorted=3 id=ageAge/th
th sorted=4 id=sexSex/th
/tr
/thead
tbody
tr
tdRead/td
tdMary/td
td25/td
tdf/td
/tr
tr
tdSparrow/td
tdJack/td
td32/td
tdm/td
/tr
...
/tbody
/table
1. If the user clicks on the header Age (or does a respective
interaction provided by the UAs sorting UI), the table should be sorted
by the age column. If ist is already sorted by this column, the sort
direction should be reversed.
2. Authors should be able to provide external links or buttons that can:
- Sort by a column as described in 1.
- Sort by a column, force ascending
- Sort by a column, force descending
I believe that this could be achieved with the following additions:
- a th.sortedstate attribute to question if the table is currently
sorted by this column, and if yes in which direction
- th.sort() method would take an optional argument to indicate the
desired sort direction
The algorithm for th.sort([String direction]) could then be extended
somehow like the following (to be simple I just write th for the
column header element that the method is applied to):
- Temporarily set the column key ordinality of th to 0
- If the direction argument is provided (and valid), temporarily set the
column sort direction to direction
- Else if the sortedstate attribute of th is not null
- if it is asc, temporarily set the column sort direction to desc
- else temporarily set the column sort direction to asc
- Perform the table sorting steps
- Set the sortedstate attributes of all column headers to null
- Set the sortetstate attribute of th to the column sort direction
- Reset the column sort direction and the column key ordinality of th to
their initial values
aside
Furthermore, a table.sort() method would be handy. It could take a comma
separated string as an argument, with each token being the ID of a th,
and optional the direction, such as:
button
onclick=document.getElementById('pirates').sort('sex asc, age')
Order pirates by age, women first. Click again for descending age.
/button
/aside
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
Am 05.12.2012 10:45 schrieb Jonas Sicking: I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through meta elements as well as, or instead of, using headers. I am one of those authors with limited technical background. IMHO the crucial point is that the solution works in shared hosting environments, without access to server configuration and hopefully without .htaccess hacks. Thus, everything that can be done via PHP or other server-side scripting should be ok. A meta element would be handy, but ?php header(...) ? is reasonable, too. Meta elements may have the downside that copy-paste authors who don't understand them may leave them in the code where they may be unnecessary or even harmful.
Re: [whatwg] Checkboxes that control other checkboxes
Am 22.11.2012 01:51 schrieb Ian Hickson: On Sun, 14 Aug 2011, Timo Beermann wrote: It should be able to implemet checkboxes, where by only activating/deactivating this single checkbox you can active/deactivate multiple other checkboxes. That is possible with scripting today, but it should be possible without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. I haven't added this yet, but it is already logged as a possible future extension, so it's possible it may be added in the future. What would be helpful though is examples of sites that do this kind of thing, so that we can study how necessary it is, and how to implement it. For instance, are the dependent fields always in a fieldset? Are they always other checkboxes? Is there more complex logic than just check box A is checked so those controls are enabled? This seems to be a special case of a larger problem to me. In order to make forms behave intelligently without scripting, there are more similar tasks: - Check/uncheck check and radio boxes based on the selected value of a select element (or even on the values of other input elements) - Enable/disable or make readonly any kinds of controls based on the state or value of an other element - Or even show/hide a set of elements based on the state or value of an other element Maybe, instead of adding that kind of functionalities to form elements, it might be worth thinking of a different way. E.g., define a set of scripting actions that are considered as very useful for UIs, and have no security issues, and let UAs execute that kind of scripts even if scripting is actually disabled, or let UAs offer a user setting such as Allow only useful form actions or whatever.
Re: [whatwg] A plea to Hixie to adopt main
Am 07.11.2012 15:48 schrieb Jukka K. Korpela: I suppose that the heuristics would include recognizing a div element to which class main has been assigned. Then one could argue that main is not needed, as authors can keep using div class=main, as millions of pages use. I doubt that this is useable for that kind of heuristics anyway - as there is no standard for this, main as a class name may indicate the main contents, but also a main container to center the whole page. Also, non-english speaking coders may use their own language words as id or class names.
Re: [whatwg] Features for responsive Web design
Am 10.10.2012 20:36 schrieb Ian Hickson: On Wed, 10 Oct 2012, Tim Kadlec wrote: That's actually exactly why it's better _not_ to plan for it. We can't design features for problems we don't understand. It's better to wait until we have real problems before fixing them. You may not be able to predict every future problem, but surely you need to keep it in mind as you create solutions for today, right? Sure, that's why for example the srcset= syntax is extensible and already supports arbitrary densities, not just 1x and 2x. Tim's objection does not only apply to the spec, but also to the code that can be written according to that spec. IMHO as an author, the bandwidth use case is not solved in a future proof manner, if I have to indicate pixel densities (or other device properties) that I serve images for, because I have no idea what devices will be available in a few years. I would have to change my code when new devices with other characteristics occur. I'd rather indicate some properties of the image files, such as pixel width or heigth, and/or KB size, and let the device resp. browser decide which one of the set it considers most appropriate for the browsing situation.
Re: [whatwg] Features for responsive Web design
Am 11.10.2012 18:36 schrieb Ian Hickson: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html It looks like my English is not perfectly understandable, I am sorry I am not a native English speaker. I did not try to state the use case was solved. I have been following the discussion in this list quite closely. My point is, that any device-specific notation, such as 2x, forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices. This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w Where 200w is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever.
Re: [whatwg] srcset isn't future-friendly to screen size differences
Am 07.09.2012 03:36 schrieb Tab Atkins Jr.: This email is an extension of the thread started at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036953.html by John Mellor, distilling the core problem he has into a more easily-understood and digested form. The srcset attribute, as currently written, is not friendly to large screen-size differences that don't trigger different art direction. Consider the following example: img srcset=800.jpg 1x, 1600.jpg 2x style=width: 100%; height: auto; For a screen that's somewhere near 800px wide, this works just fine. However, a 1x screen 1600px wide (not too uncommon - I think a 19 monitor is roughly that width) will get served the 800.jpg image, which then gets blown up to an unattractive level. The 1600.jpg file should be identical to the 800.jpg file, just higher resolution, so delivering it instead would be ideal, but the current syntax doesn't allow that, nor does it allow any reasonably reliable way for a browser to detect that it would be okay to serve the 1600.jpg image either. I'm not sure how best to solve this, but John Mellor suggested allowing the specification of the image's native dimensions somehow. That way, the browser could know that the 1600.jpg image is appropriate to serve as an 800px wide high-dpi image, or a 1600px wide low-dpi image. With respect to the threads on responsive images of the last few months, IMHO it is not possible to solve both art direction and bandwidth use cases with the same syntax in a satisfactory manner: - Art direction use case: Should be controlled by the author, which is possible via some kind of MQ. - Bandwidth use case: As you state above, this use case should be better controlled by the UA. The UA does not need MQs to make a good selection, but rather information on the image files available. The problem of @srcset is that on one hand it can't convey image dimensions, and on the other hand it's MQ possibilities are very limited and not extensible if things evolve in the future. This has been discussed in several places of the related threads in the last few weeks. I'd like to revive Florian Rivoal's (and my) suggestion of using picture for the art direction and @srcset for the bandwidth use case, so you can optimize bandwidth inside art-directed images. *But with the modification, that @srcset takes image dimensions rather than page dimensions:* img srcset=big.jpg 800w, normal.jpg 400w, small.jpg 200w src=normal.jpg style=width:100% img srcset=16.jpg 240h, 12.jpg 180h src=16.jpg style=height:15em picture alt= source srcset=mobile.jpg 200w, mobile-hd.jpg 400w source media=min-width: 600px srcset=large.jpg 540w, larger.jpg 1080w, giant.jpg 2160w img src=mobile.jpg /picture Note that with this change there is no more 1x default for the source element, thus a src attribute does not seem to make sense there.
Re: [whatwg] Features for responsive Web design
Am 13.08.2012 18:39 schrieb Henri Sivonen: Ignoring implementation issues for a moment, I think it would be conceptually easier it to disentangle these axes like this: Non-art directed: img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative Art directed: picture source src=1xsampling-cropped.jpg hisrc=2xsampling-cropped.jpg media=max-width: 480px img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative /picture I like this hisrc approach for its simplicity; it depends on the question whether a limit of 2 sources for the bandwidth use case is considered to be okay. Anyway, I think it is an important question, as there may be future use cases that require more than 2 sources, such as providing an extra source for printing (which may be a 3x or 4x pixel format or a vector format), or progressive loading of sources as I described here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036884.html Anyway both these cases are hypothetic, and the print use case may also be solved via picture and media=print. From an author's POV, hisrc looks quite intuitive and easy to use to me.
Re: [whatwg] Features for responsive Web design
Am 10.08.2012 12:06 schrieb Odin Hørthe Omdal: On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński kor...@geekhood.net wrote: One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). I don't see the big problem, I think the spec is fine here. Yes it allows for putting a float there, but authors won't use it, so what's the problem? The spec already say you should use the number to calculate the correct intrinsic size, and the implementation will know what to do with a float number there if someone finds an actual use for it. This isn't limiting it for the sake of making anything easier, it's not like the x is an integer is any easier than the x is a float. And if you *do* somehow find a good use for it down the line (and I believe there might be, maybe 0.5x) it'll be there and work. No harm. :) One hypothetic use case for 0.5x could be: Future UAs may want to progressively load sources in order to display a lowres image very quickly, and increase quality if there is enough bandwidth to do so, similarly to what we know from interlaced GIFs. Authors then might want to provide 0.5x and even 0.25x sources for this purpose.
Re: [whatwg] Features for responsive Web design
Am 07.08.2012 21:09 schrieb Ian Hickson: On Tue, 22 May 2012, Markus Ernst wrote: Am 18.05.2012 23:19 schrieb Kornel Lesiński: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Maybe the use cases should be solved independent from each other: - Use picture for the art direction use case. - Remove the MQ except the pixel density from @srcset, and make @srcset available in both img and source: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x picture alt= source src=mobile.jpg srcset=low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x source src=large.jpg media=min-width: 600px srcset=large.jpg 1x, large-high.jpg 2x img src=mobile.jpg /picture I don't understand why this is better than: img src=large.jpg alt= srcset=low.jpg 600w 0.5x, mobile.jpg 600w 1x, mobile-hd.jpg 600w 2x, large-high.jpg 2x It seems to me that srcset as specified does exactly the same thing, but more succintly. [...] On Thu, 24 May 2012, Florian Rivoal wrote: picture source srcset=normal.jpg 1x, highres.jpg 2x source media=(max-width:768px) srcset=ipad.jpg 1x, ipad3.jpg 2x source media=(max-width:320px) srcset=iphone.jpg 1x, iphone4.jpg 2x img src=normal.jpg /picture I don't understand why this is better than: img src=normal.jpg srcset=highres.jpg 2x, ipad.jpg 768w 1x, ipad3.jpg 768w 2x, iphone.jpg 320w 1x, iphone4.jpg 320w 2x alt=... ...which as far as I can tell does exactly the same thing. It is better because art direction and bandwidth use cases can be solved differently in an appropriate manner: - For the bandwidth use case, no MQ is needed, but only some information on the sources available to let the UA decide which source to load. - For the art direction use case OTOH, the picture element is more intuitive to handle and also easier to script, as sources can be added or removed via DOM. Anyway, with your proposal, would this be valid, to address the bandwidth-only use case?: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x
Re: [whatwg] Can we make checkboxes readonly?
Am 11.07.2012 00:59 schrieb Ian Hickson: On Fri, 4 May 2012, Tab Atkins Jr. wrote: On Wed, May 2, 2012 at 3:57 PM, Ian Hicksoni...@hixie.ch wrote: On Wed, 6 Apr 2011, Tab Atkins Jr. wrote: An app may dynamically set inputs or groups of inputs to readonly based on app state. When you submit, though, it's impossible to tell (without hacks) whether a checkbox was checked-but-disabled or just unchecked. Handling the form data is *much* easier if you just get all the data, regardless of whether, as a UI convenience, your app temporarily set some of the inputs to readonly. That's a use case for submitting disabled check boxes, not for read-only checkboxes, IMHO. (The same could be said for disabled text controls.) That's more-or-less what @readonly does - the input becomes disabled but still submits. That's part of what it does, but not the main thing it does. It's mainly a UI affordance, which doesn't apply to check boxes. Given that there are valid use cases for submitting values of elements that have a disabled resp. readonly behaviour in the UI: Would it do any _harm_ to allow @readonly to checkboxes and radio buttons? I assume this would be easy and possible without breaking existing content. Submitting disabled elements, OTOH, looks to me like an impossible change, as it would likely break existing content.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 06.06.2012 14:36 schrieb Henri Sivonen: On Wed, May 23, 2012 at 6:21 PM, Florian Rivoalflori...@opera.com wrote: 1) simplyfy srcset to only accept the *x qualifier Is there a good reason to believe that * will be something other than a power of two? That is, could we just optimize the *x syntax away and specify that the first option is 1x, the second is 2x, the third is 4x, etc.? Explicitly specifying the * in *x allows more flexibility in the future for cases such as: - If sometime most displays will have 2x or higher resolutions, authors might want to set 1x versions aside. - If 3x or whatever displays should occur, the spec should be suitable for them, too. - Some UAs might decide to progressively load sources in order to emulate what we know from interlaced GIFs. Authors could for this purpose add 0.5x and even 0.25x versions.
Re: [whatwg] AllowSeamless
Am 27.05.2012 02:16 schrieb Adam Barth: Hi whatwg, I've added a proposal to the wiki http://wiki.whatwg.org/wiki/AllowSeamless about letting a document indicate that it is willing to be displayed seamlessly with a cross-origin parent. This proposal is a refinement of the approach previously discussed in this thread: http://old.nabble.com/crossorigin-property-on-iframe-td33677754.html. Let me know if you have any feedback. I have a strong feeling that per-origin control should be made easy for authors. I must admit that I am not familiar with the mechanisms you name, Frame-Options and ancestor-origins - and both are quite hard to google for. From what I found I assume both are about HTTP headers. If they are solutions that can be used easily with server-side languages such as PHP, I think we can live with it. But anyway it is a complication; I'd personnally prefer something like allowseemles=example.org, *.example.org, shop.otherdomain.com Or maybe space separated, and separate inherit-style with comma: allowseemles=example.org *.example.org shop.otherdomain.com, inherit-style (Regardless of whether it is in the HTML element or in a META element.) -- Markus
Re: [whatwg] AllowSeamless
Am 27.05.2012 12:00 schrieb Markus Ernst: allowseemles=example.org *.example.org shop.otherdomain.com, inherit-style It seams I made a typo here.
Re: [whatwg] AllowSeamless
Am 27.05.2012 12:19 schrieb Adam Barth: On Sun, May 27, 2012 at 3:00 AM, Markus Ernstderer...@gmx.ch wrote: Am 27.05.2012 02:16 schrieb Adam Barth: I've added a proposal to the wiki http://wiki.whatwg.org/wiki/AllowSeamlessabout letting a document indicate that it is willing to be displayed seamlessly with a cross-origin parent. This proposal is a refinement of the approach previously discussed in this thread: http://old.nabble.com/crossorigin-property-on-iframe-td33677754.html. Let me know if you have any feedback. I have a strong feeling that per-origin control should be made easy for authors. I must admit that I am not familiar with the mechanisms you name, Frame-Options and ancestor-origins - and both are quite hard to google for. From what I found I assume both are about HTTP headers. If they are solutions that can be used easily with server-side languages such as PHP, I think we can live with it. But anyway it is a complication; I'd personnally prefer something like allowseemles=example.org, *.example.org, shop.otherdomain.com Or maybe space separated, and separate inherit-style with comma: allowseemles=example.org *.example.org shop.otherdomain.com, inherit-style (Regardless of whether it is in the HTML element or in a META element.) I had difficulty coming up with use cases that weren't better served with frame-ancestors and/or Frame-Options. Do you have a specific use case in mind to explain your feelings? My use case is a content provider, who provides e.g. a Sudoku application or a weather forecast for wind surfers. Paying customers are allowed to embed the content seamlessly in their web sites. The content can also be embedded for free, but not seamlessly. The content provider includes some corporate info, such as his/her own logo, and a provided by XY notice and link to his/her own page. The paying customers then can apply their own styling, and set the corporate info to display:none in the style sheet of the top document, via seamless embedding.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 24.05.2012 10:27 schrieb Matthew Wilcox: Excellent, sorry I was not clear on that; this is looking good! I would like to re-iterate that this solution is another which puts design properties into mark-up directly, and just like oldpicture and srcset, this means that when it's time to re-design a site an author is going to have to trawl through allpicture elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. This is true only for the art-direction use case, as MQs are removed from the optimization use case. Unless a new proposal comes up that solves this issue, too, I think this is something we can live with, for two reasons: - The art direction use case is somehow at the edge between content and design. Serving a cropped version of an image is actually dealing with content, even if it is about the design situation. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. In my practice I have seen several redesigns of websites; none of them was restricted to CSS, in all cases, the whole websites were rebuilt, or at least the content was entirely reviewed. (My experience is very much focused on corporate situations, so this may be different in other fields such as academic.)
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 24.05.2012 11:13 schrieb Matthew Wilcox: I agree, the problem is that... it's still a problem. It's not always a cropped version, it's sometimes a different image entirely - but we can only sense the viewport rather than the space into which an image is sitting. Because we can only sense the viewport we are actually hooking into the design itself rather than being able to automate things based on how much room is there for this image?. However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. Once CSS variables are available, would it be possible to reference them from the @media attribute? Given a variable breakpoint1 is defined in the CSS file: source media=(min-width:var(breakpoint1)) srcset=tall.jpg 1x, tall2.jpg 2x
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 23.05.2012 17:21 schrieb Florian Rivoal: Here's what I think we should do: 1) simplyfy srcset to only accept the *x qualifier 2) add support for srcset as an attribute of the source sub-element of the picture element (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: picture source media=(orientation:landscape) srcset=long.jpg 1x, long2.jpg 2x source media=(orientation:portrait) srcset=tall.jpg 1x, tall2.jpg 2x img src=fallback.jpg / /picture Yesterday I made a similar proposal in an other thread: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036143.html I'd like to suggest that @srcset in this form would also be suitable for the img element, to address the optimization use case (without art direction) without the verbosity of picture.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 21.05.2012 07:49 schrieb Mike Gossmann:
img src=/img/people.jpg sizes=100x200 300x250 900x300
pattern=/tools/resizer.php?img=people.jpgamp;width={w}amp;height={h} alt=A picture of some
people.
I am somehow surprised that there are no reactions to this proposal. To
me as a humble author it looks like it would address the main issue of
both picture and @srcset, as it leaves the MQ to CSS, and thus
separates design from content.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 22.05.2012 12:46 schrieb Andy Davies:
On 22 May 2012 10:43, Anne van Kesterenann...@annevk.nl wrote:
On Tue, May 22, 2012 at 10:21 AM, Markus Ernstderer...@gmx.ch wrote:
I am somehow surprised that there are no reactions to this proposal. To me
as a humble author it looks like it would address the main issue of both
picture and @srcset, as it leaves the MQ to CSS, and thus separates design
from content.
1. It does not address the pixel density use case. 2. A pattern-based
approach was actually mentioned in Ian Hickson's email when he
announced the srcset attribute.
It doesn't address the art-direction use case either -
http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/
You can do art direction by setting the width in the style sheet:
@media all and (max-width: 500px) {
.contentimg {
width: 100px;
}
}
@media all and (min-width: 501px) and (max-width: 800px) {
.contentimg {
width: 300px;
}
}
@media all and (min-width: 801px) {
.contentimg {
width: 500px;
}
}
img class=contentimg
src=img/obama-500x333.jpg
sizes=100x67 200x134 300x200 500x333
pattern=img/obama-{w}x{h}.jpg
alt=President Obama speaking at a Chrysler plant
You supply a cropped image with 100x67 and 200x134 versions, and the
full image with the bigger versions, which serves the art direction use
case. Retina displays that match the first MQ will likely use the
200x134 version rather than the 100x67 one, which serves the pixel
density use case.
I admit that it is not entirely intuitive, and does not give the author
full control. There may be conflicts between a cropped 200px wide image
intended to use in 2x displays, and a full 200px wide image for bigger
but 1x displays. Or a future 3x display may use the 300x200 version,
where the visual situation would require the cropped image.
I am far away from insisting in this solution; I am aware of the fact
that there have been long discussions by people who have far more
understanding on the topic than myself.
It looks to me like the pixel density use case is better addressed by
leaving the choice on the appropriate resource to the UA, and providing
it information on the resources rather than a MQ. While the art
direction use case is better addressed with a MQ undoubtedly.
Re: [whatwg] Features for responsive Web design
Am 18.05.2012 23:19 schrieb Kornel Lesiński: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Maybe the use cases should be solved independent from each other: - Use picture for the art direction use case. - Remove the MQ except the pixel density from @srcset, and make @srcset available in both img and source: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x picture alt= source src=mobile.jpg srcset=low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x source src=large.jpg media=min-width: 600px srcset=large.jpg 1x, large-high.jpg 2x img src=mobile.jpg /picture This leaves the whole design choice to the author, and gives the UA the full choice on what resource to use. Instead of coping with various kinds of MQs, the author can just specify the sources available, and the UA will make the choice based on the situation. The 0.5px version in my example would be intended for use with very low bandwidth, or for a UA that may progressively load sources as we know it from old progressive GIFs.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 21.05.2012 07:49 schrieb Mike Gossmann:
When all the picture vs srcset started showing up on twitter, I was initially
behind picture. I'm sure you all know the arguments for it, and I liked those
arguments. Today though, I was reading an article about the two, and there was
a misunderstanding about how srcset was working in the comments, and it made me
realize that something closer to srcset would be ideal.
The big thing I realized is that as a developer, I do not want to write more
media queries - or anything that works at all like them - into image elements.
It's redundant. There's a good chance there's already a bunch of CSS in place
controlling the shape and size of the image element itself, why should I have
to write a bunch more, somewhere else, to control the src of the image too?
Why can't it work so that in the html I say here's an image, there's a version
of it at 150x150, and a version at 48x48, and then in the CSS I say that the
image is 25% of the width of the article it's in, which works out to 100px
wide, and then the browser can just decide that the 150x150 would be best, and
scale it down. If I change the CSS, I don't have to change the html too, the
images I provided are still only available at those sizes. With image/picture
sources set by viewport dimensions, even something as simple as adding more
padding around articles on a site could involve going through all the HTML and
adjusting the breakpoints in the tags. This way layout, units, and screen dpi,
don't matter when writing the HTML,
I've seen people get confused and think srcset work this way, instead of by
viewport size (unless I'm the confused one), and if they were right then srcset
would work well for this. It would be even nicer if there was something even
more CMS friendly, like:
img src=/img/people.jpg sizes=100x200 300x250 900x300
pattern=/tools/resizer.php?img=people.jpgamp;width={w}amp;height={h} alt=A picture of some
people.
So src would be the fallback, then sizes would say which dimensions are available, in a fairly
common format, using spaces to separate options like class does. pattern (probably a bad name)
would be a template for the URL the browser can request the image from, replacing {w} and {h} with
the requested dimensions. There wouldn't need to be a token for the dpi/resoultion/whatever, the
browser could just request an image twice or three times or whatever the size. There's no point in
having sizes=100x100@1 100x100@2 200x200@1 when you can just have sizes=100x100
200x200
This gives the designer/developer full control over the shape and size of the
image element (through CSS), while still allowing the browser to make decisions
based on bandwidth and whatnot.
I was actually writing a similar proposal and like the approach very
much. I have 3 inputs on the pattern syntax:
1. @pattern needs some more variables so authors can use it without a
server side handler, using distinct file names or directories or
whatever, such as:
- directory path
- file name
- file name without suffix
- suffix
So patterns for use with src=/img/people.jpg could also be e.g.
(variable names are subject to optimisation...):
- /img/{filenameWithoutSuffix}_{w}x{h}.{suffix}
- /{dirname}/{w}x{h}/{filename}
2. It would be nice if @pattern defaulted to something that authors do
all the time anyway. From my practice I suggest:
- /{dirname}/{filenameWithoutSuffix}_{w}x{h}.{suffix}
It is very easy to tell authors or even CMS page admins to use image
file names such as people.jpg and people_200x300.jpg.
3. Variable syntax: Curly brackets are also used for variables by some
server side template engines, such as PEAR HTML_Template_IT and
HTML_Template_Sigma. These would replace or remove the @pattern
variables. Thus, some other kind of variable delimiter might be more
compatible.
Re: [whatwg] Problems with width/height descriptors in srcset
Am 17.05.2012 19:48 schrieb Tab Atkins Jr.: On Thu, May 17, 2012 at 10:27 AM, Jeremy Keithjer...@adactio.com wrote: Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. img src=small.png srcset=medium.png min-width:600px, large.png min-width: 800px or img src=large.png srcset=medium.png max-width:800px, small.png max-width: 600px Yes, you got it. Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a Mobile First or Desktop First approach according to their preference. Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). No, if we're aping the CSS syntax more closely, we should just use CSS units. h1img src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/h1 pimg src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/p Is em different in these 2 elements, or is it actually rem? And whatever answer, is it a problem or a feature?
Re: [whatwg] Features for responsive Web design
Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset.
Re: [whatwg] Features for responsive Web design
Am 18.05.2012 13:09 schrieb James Graham: On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account. One use case is manipulating content in a contenteditable area, e.g. in a Rich text editor. A JS-based online editor such as TinyMCE or KTML may want to offer some kind of GUI for alternative sources. I am not sure whether this is a very important use case, as authors of online editors are usually JS experts and capable of writing complex string operations, too; but I assume the use case is at least valid.
[whatwg] Responsive images and printing/zooming
Hello I try to follow the actual discussion with much interest and, I admit, not full understanding. If my inputs are inappropriate, please feel free to ignore this message. I read the current spec and huge parts of today's discussions to find out how images with multiple sources are intended to behave when printed, or when the page is zoomed, but I found no hints. I think some words on this might be useful in the spec, regardless of what the final syntax will be. 1. Print When a page is printed (or also converted to PDF or whatever), both viewport width and pixel ratio change. Are UAs expected to load the appropriate sources then? This could result in increased bandwidth, delayed printing, and IMHO a disturbed user experience, as the image may differ from the one seen on screen. Thus, I suggest to always use the resource actually shown on screen for printing. 2. Zoom On mobile devices, web pages are often zoomed out to fit the viewport width by default, the user is supposed to manually zoom in and scroll in order to read parts of pages. I understand that the whole thing about responsive design is to make this kind of zooming unnecessary, but in practice there will be all kinds of partly responsive designs using responsive images. Specially in cases where separate sources are given to match device pixel densities, zooming might matter, as for a zoomed-out page the low res image might be more than sufficient, but after zooming in the higher resolution might be appropriate. Which OTOH can disturb the user experience, when the images differ.
Re: [whatwg] restricted palette for input type=color
Am 03.05.2012 00:50 schrieb Ian Hickson: On Mon, 7 Mar 2011, Markus Ernst wrote: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. You don't really need a colour picker for that... it's more aselect than a colour picker. Or a series of radio buttons. If the presentation is more the concern, then we should probably rely on Web Components to solve the problem (styling aselect with a new presentation, e.g.). It is actually an input field that requires a valid color to be entered; whether it is presented as a color picker or a select box may be up to the UA. I don't see any consistency in having to use different HTML elements whether the selection of colors is defined by the UA (e.g. showing a picker with all colors of the web palette) or by the author. Anyway, 4.10.7.1.15 of the spec states in the bookkeeping details that the @list content and IDL attributes apply to input type=color - if I understand this correctly, it addresses my proposal. [...] - The fact that most CMS do not have restricted color sets so far, does not mean there is no demand for it, but rather shows the difficulty of customizing tools such as TinyMCE. It is a hassle for CMS implementors (who are often not highly skilled JS programmers), if they are expected to respect corporate design guidelines. I don't follow. Right now (before type=color is widely implemented) it's easier to provide a limited set of colours than all colours. Surely then we should see more CMSes have restricted colour sets if it's a matter of difficulty. The CMS I know are shipped with TinyMCE or KHTML or whatever rich text editors. They usually provide a color picker with a predefined set of colors (iirc it is mostly the web palette) by default, which is non-trivial to override or customize; IMHO this is the reason why customized color pickers are not widely used. There are definitely use cases for them.
[whatwg] Allow empty string for input type=color
I apologize in case this has been discussed before - the list archive search seems to be broken right now, as it does not find any matches when searching for color. I just noticed a note in the spec of input type=color http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#color-state-%28type=color%29: Note: In this state, there is always a color picked, and there is no way to set the value to the empty string. If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. I see the following reasons for allowing the empty string: 1. An application might want to give the user the choice of not selecting a color. Not specifying a color is the easiest way to state that the default color should be used, be it black or other. 2. An application might want to force the user to make an explicit selection. It may not be able to distinguish whether black was explicitly selected, or the user forgot to specify a color. 3. Applications need to deal with the empty string anyway, as legacy browsers show a text field.
Re: [whatwg] crossorigin property on iframe
Am 12.04.2012 22:35 schrieb Ojan Vafai: On Thu, Apr 12, 2012 at 1:32 PM, Adam Barthw...@adambarth.com wrote: On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafaio...@chromium.org wrote: On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarskybzbar...@mit.edu wrote: On 4/12/12 3:49 PM, Adam Barth wrote: The seamless part might be workable, since that leaks information only from the document in question. It's possible that there's a better mechanism than CORS for a child frame to opt into being seamless with its parent. Yes, I agree that having a way for a child to opt into being seamless is desirable. That doesn't have the problems direct DOM access does. OK, I'm convinced that direct DOM access is a bad idea. seamless was the use-case I most cared about anyways. In theory, if we use seamless + CORS for the @src load and any navigations of the frame (including via Location), then this should be feasible, yes? Alternately, we could add a special http header and/or meta tag for this, like x-frame-options, but for the child frame to define it's relationship to the parent frame. The reason we have the crossorigin attribute forimg andscript is because the request needs to follow the CORS rules, which means we need to know ahead of time how to make the request. In this case, we don't need to know whether the child wants to opt into cross-origin seamlessness until we get the response. For that reason, something like an attribute on thehtml element might be a better mechanism than CORS. Sounds fine to me. allowseamless? embedded-frame-options=allowseamless? The latter would give future extensibility if we wanted to ad other embedding options. I assume that one popular use case for seamlessly embedding cross-origin frame content is: A service provider allows his/her customers to embed the pages provided. In this case, the info needed is a list of domains that are allowed to embed the content, rather than an allowseemless yes/no flag. As an author, I think a meta element would be handy, something like: meta name=allow-seemless-embedding content=domain1.com, domain2.co.uk, shop.domain3.net I don't know whether the list should rather be space or comma separated. Subdomains of the specified domains should inherit the allowance, the way that www.domain1.com and test.domain1.com can seamlessly embed the page, but not www.domain3.net or even foo.co.uk.
Re: [whatwg] seamless iframes
Am 05.04.2012 03:59 schrieb Ojan Vafai:
On Wed, Apr 4, 2012 at 6:52 PM, Ojan Vafaio...@chromium.org wrote:
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
uses, seamless iframes will not want a border and will want to fill their
container. This way, seamless iframes behave roughly like sandboxable divs,
which is what web developers want.
2. http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless In
visual media, in a CSS-supporting user agent: the user agent should set the
intrinsic width of the iframe to the width that the element would have if
it was a non-replaced block-level element with 'width: auto'.
This doesn't get the behavior you'd want with cases that need
shrink-wrapped behavior. Some cases that need handling:
iframe seamless style=display:inline
iframe seamless style=display:inline-block
iframe seamless style=float:left
iframe seamless style=position:absolute
3. The default margin on the body element inside a seamless iframe should
be 0. Again, this is what 90%+ of uses will expect. We shouldn't require
everyone using seamless iframes to have to set the body's margin to 0.
As a developer, I am very happy about this suggestion. Please note there
was a discussion on parts of this topic, starting here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027011.html
(I am sorry the examples I linked to are not online anymore.)
Re: [whatwg] add html-attribute for responsive images
Am 25.01.2012 16:39 schrieb Matthew Wilcox: It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. This use case shows some kind of consistency issue: The printed version of a page might match a different media query, and thus use a different image. If the images have different contents, this can result in a confusing user experience. In order to work around this, UAs might want to keep the first image loaded, when the content is used for a different type of media, such as print or PDF output. (That could also be the case for changes of window size.) There was some more discussion on this type of use case: Am 25.01.2012 14:42 schrieb David Goss: On Tue, 24 Jan 2012 23:26, Ian Hickson wrote: What's the use case for doing it for images inimg elements? Typically img elements are for content images, where you don't usually want to adapt anything. On Tue, 30 Aug 2011, Karl Dubost wrote: And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px I don't understand the use case. For something like a user profile icon surely it would be rather bad UI to use a different icon on different devices. I presume you don't mean a profile icon though, since 1024x250 is a bit excessive for an icon these days, and I'm not aware of any site that lets users pick different icons for different size contexts. The use case is that you want to serve the same image (same content) to all users, but you want to serve it in different resolutions depending on their context to avoid wasting bandwidth and killing performance (especially on mobile devices where performance is key - you don't want to download a 1000px-wide image when you're scaling it down to 320px wide to display it). Karl's example is on dangerous ground, IMO. The different sizes of the image could be slightly cropped/zoomed as appropriate, but should still clearly represent the same thing - in other words, the same alt text should correctly describe all of them.
Re: [whatwg] add html-attribute for responsive images
Am 25.01.2012 15:07 schrieb Matthew Wilcox:
In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):
http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/
I would like to propose a use case different from the ones in this
blog-post: Scaled images.
The more physical screen densities improve, the less image pixels
actually correspond to device pixels, and thus scaling images will be
less a problem. E.g., designers might want to define an image size in em
units rather than in px, so it keeps its relation to the text size.
This use case requires a negotiation based on the dimensions of the
image element rather than the dimensions of the media. It would be nice
if a solution to the responsive images problem would address this use
case, too. AFAICS this would require a more general syntax for the
conditions.
On 25 January 2012 13:42, David Gossdvdg...@gmail.com wrote:
I'm proposing this (adapted from Bruce Lawson'spicture idea, and similar
to how thevideo element works):
adaptiveimg
img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool
source src=sweater-medium.jpg media=(min-width: 300px) and
(max-width: 450px)
source src=sweater-large.jpg media=(min-width: 451px) and
(max-width: 600px)
source src=sweater-huge.jpg media=(min-width: 601px)
/adaptiveimg
If the introduction of a new element is an option, it could also be the
other way around, as image maps work:
img src=default.gif srclist=mySrcList id=myImg alt=My responsive
image style=width:5em;height:auto
srclist id=mySrcList
source src=low.gif cond=[condition]
source src=high.gif cond=[condition]
/srclist
To address my above use case, I replaced the media attribute with a more
general cond attibute, which can take a condition with a selector and a
rule. The selector can be the keyword media or a CSS selector, and the
rule either a min-width and/or max-width declaration, or some statement
about network speed or whatever, such as:
source src=small.gif cond=#myImg{max-width:49px}
source src=medium.gif cond=#myImg{min-width:50px;max-width:99px}
or:
source src=small.gif cond=#wrapper{max-width:320px}
or:
source src=small.gif cond=media{max-width:320px}
or:
source src=slow.gif cond=media{network-speed:[some slow value]}
Re: [whatwg] Localisation of form fields
Am 21.01.2012 15:19 schrieb Cameron Heavon-Jones: On 20/01/2012, at 6:58 PM, Bronislav Klučka wrote: Hello There are two recent threads on localisation of form fields, one on input type=date, the other on the Decimal comma in numeric input. Both are about the question whether the form field value should be displayed according to the element's language, or rather based on the user's preferred locale. This looks like a basically interesting question to me; I see use cases for both: Use case for using User's preferred locale: - The user is viewing a website in a foreign language, using his/her own computer. Use case for using the element's language: - The user is viewing a website in his/her own language, but using a computer in an internet café in a foreign country (where (s)he might not even be able to change the language settings of the browser). As some formats may be very different, both situations can lead to misunderstanding of the values displayed in the form, and thus wrong submissions. It was pointed out, that the comma may be a 1000 or a decimal separator. Or, dates are arranged differently, e.g. M/D/Y in English, but D.M.Y in German. This makes me think, if UAs could be encouraged to invent some kind of UI for per-session overriding the localisation settings of both UA and website content. I think translation is the word here and accurately identifies the potentially inaccurate process taking place. Thanks, Cameron Jones No, localization is, localization goes beyond simple translation Brona Yes, but my point is that what is really desired here is translation, not localization. If the representation is within a specific language\locale and the user desires a different language\locale then that process is one of translation including transformation of localization. I see that point. Reading the Decimal comma discussion, I am sure a simple per-session method to translate form input formats into other locales (without translating text) would be a handy thing, but I admit this list may not be the appropriate place to discuss it.
[whatwg] Localisation of form fields
Hello There are two recent threads on localisation of form fields, one on input type=date, the other on the Decimal comma in numeric input. Both are about the question whether the form field value should be displayed according to the element's language, or rather based on the user's preferred locale. This looks like a basically interesting question to me; I see use cases for both: Use case for using User's preferred locale: - The user is viewing a website in a foreign language, using his/her own computer. Use case for using the element's language: - The user is viewing a website in his/her own language, but using a computer in an internet café in a foreign country (where (s)he might not even be able to change the language settings of the browser). As some formats may be very different, both situations can lead to misunderstanding of the values displayed in the form, and thus wrong submissions. It was pointed out, that the comma may be a 1000 or a decimal separator. Or, dates are arranged differently, e.g. M/D/Y in English, but D.M.Y in German. This makes me think, if UAs could be encouraged to invent some kind of UI for per-session overriding the localisation settings of both UA and website content.
[whatwg] Proposal: Exclude robots on a per-link basis
Hello Viewing the logs of applications I wrote, I noticed that a considerable number of requests are from robots following links of types such as Add to shopping cart or Remember this item - links that typically point to the same page they are clicked on, with some GET variable that triggers an action on the server. Trying to find a solution to tell robots not to follow these links, I came across microformat Robots Exclusion Profile http://microformats.org/wiki/robots-exclusion and the @rel=nofollow attribute. While the latter does not look robot-specific to me (it actually states that the author wants to discourage from following the link), I must admit that I don't fully understand the Robots Exclusion Profile approach. If this approach is serving the purpose, please feel free to ignore this proposal. It might then be helpful to add some hint on this somewhere in 4.12 of the HTML spec. I propose to add either a new attribute, or a new link type, or a keyword for @rel, whichever is most consistent in the HTML structure: a href=page.html?add-item=1 robots-nofollowAdd to cart/a a href=page.html?add-item=1 rel=robots-nofollowAdd to cart/a a href=page.html?add-item=1 type=robots-nofollowAdd to cart/a -- Markus
Re: [whatwg] Handling of collapsed whitespace in contenteditable
Am 21.06.2011 02:16 schrieb Ojan Vafai: It is certainly the case that some large subset of users use spaces to align content, not to mention really care about things like two spaces after periods, etc. One way or another, contentEditable needs to support this. If we were starting with a clean slate, the editing behavior we want is likely whitespace:pre-wrap + some logic about what to do when you put extra spaces at the end of a line*. We should make sure the pre-wrap editing works as well as possible (e.g. doesn't do any of these NBSP shenanigans), but we have to support non-pre-wrap even if it's not the default. So, one way or another, we need to spec this behavior. I agree. I personnally would appreciate a use NBSPs for consecutive spaces setting that can be turned on or off. For BC reasons it will have to be on by default. An author who is aware of this and able to turn this setting off, will also be aware of the possibility to apply white-space:pre-wrap to the contenteditable element. Therefore I suggest to leave this up to the author. It does not look consistent to me to apply different default values for the white-space property based on the contenteditableness of an element. (At least, I would find it easier to answer the question Why do my spaces disappear while typing? than the question Why does my content look different though I use the same CSS for the editor and the target page of the edited text?.)
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
Am 14.06.2011 18:06 schrieb Tab Atkins Jr.: On Tue, Jun 14, 2011 at 2:04 AM, Markus Ernstderer...@gmx.ch wrote: Am 14.06.2011 09:32 schrieb Ian Hickson: On Fri, 11 Mar 2011, Markus Ernst wrote: Consider this markup of Andy's use case: pI always like to eat these cheeses: il iliCheddar/ili, iliStilton/ili, and iliRed Lester/ili, /il but I enjoy them most with one of these biscuits: il iliwheat crackers/ili, ilirye crackers/ili, ilidigestives/ili, /il and some chutney./p ilstands for inline list,ilifor inline list item (it's a pity we can't reuselifor BC reasons). Conforming UAs would be required to ignore any content in anilelement, except it is in anilielement. Like that, the above example would be perfectly readable in legacy UAs, but make sense in HTML5-capable UAs. It would even be easy to stlye the output for legacy UAs supporting display:list-item, as this example illustrates: http://www.markusernst.ch/stuff_for_the_world/list-test.html What problem does this solve? It solves the first use case Jukka mentioned in his original post: Am 10.03.2011 09:20 schrieb Jukka K. Korpela: Thep element (ever since it became an element) has always allowed inline (text-level) content only, and no change is planned to this in HTML5. Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example? So does Hixie's answer of Tell them to use twops and aul. His answer has the benefit of not requiring any changes to HTML, and not introducing a fourth type of list that is only very subtly different fromul. Am 15.06.2011 09:09 schrieb Jukka K. Korpela: div class=p pThis is text, which may be just list header (introduction to the list) or a longer presentation. ul lian item/li lianother item/li /ul pHere we may have text that logically continues the discussion of the topic./p /div * * * I know this suggestion is long and raw, but I hope its basic content is something we can agree on. And I have no big problem with using div markup here, even though it somewhat goes against the spirit of modern HTML. This results in: div class=p pI always like to eat these cheeses:/p ul liCheddar/li, liStilton/li, and liRed Lester/li, /ul pbut I enjoy them most with one of these biscuits:/p ul liwheat crackers/li, lirye crackers/li, lidigestives/li, /ul pand some chutney./p /div I don't like this, because it is a hackish workaround for a quite basic problem. Lots of HTML is actually authored by non-programmers using online rich text editors - both the editor softwares and their users will be quite hard to teach about using such constructs. I strongly assume that the following kind of solution is more likely to occur: p style=margin-bottom:0I always like to eat these cheeses:/p ul style=margin:0 liCheddar/li, liStilton/li, and liRed Lester/li, /ul p style=margin:0but I enjoy them most with one of these biscuits:/p ul style=margin:0 liwheat crackers/li, lirye crackers/li, lidigestives/li, /ul p style=margin-top:0and some chutney./p The main issue here is the fact that you can't just apply styling to the list element, but have to apply it to the surrounding ps, too. Inline lists would make this kind of things definitely easier and better. Of course I understand the benefit of not requiring any changes to HTML, but actually the HTML5 process is about making changes to HTML. I don't have a big problem with using this kind of markup either, but the same applies for using divs instead of articles and sections.
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
Am 14.06.2011 09:32 schrieb Ian Hickson: On Fri, 11 Mar 2011, Markus Ernst wrote: Instead of a new paragraph concept, there could also be a new concept for inline (resp. Phrasing Content) lists. The concept is actually not too new - for quotes, e.g., we've had both block levelblockquote and an inline levelq elements for long. Why not the same for lists? Consider this markup of Andy's use case: pI always like to eat these cheeses: il iliCheddar/ili, iliStilton/ili, and iliRed Lester/ili, /il but I enjoy them most with one of these biscuits: il iliwheat crackers/ili, ilirye crackers/ili, ilidigestives/ili, /il and some chutney./p il stands for inline list,ili for inline list item (it's a pity we can't reuseli for BC reasons). Conforming UAs would be required to ignore any content in anil element, except it is in anili element. Like that, the above example would be perfectly readable in legacy UAs, but make sense in HTML5-capable UAs. It would even be easy to stlye the output for legacy UAs supporting display:list-item, as this example illustrates: http://www.markusernst.ch/stuff_for_the_world/list-test.html What problem does this solve? It solves the first use case Jukka mentioned in his original post: Am 10.03.2011 09:20 schrieb Jukka K. Korpela: The p element (ever since it became an element) has always allowed inline (text-level) content only, and no change is planned to this in HTML5. Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example?
[whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
While following the discussions about Aryeh Gregor's great work on execCommand(), I get the impression that this method is very limited to some basic formatting actions. It provides shortcuts for a limited set of DOM actions, but is not really extendable or generalizable. Some of the discussions were about adding support for new elements, such as header and section, or for distinctive i and em resp. b and strong elements. I doubt that extending execCommand() with specific new commands for more elements would be the direction to go. With the focus on HTML editing rather than WYSIWYG editing, some kind of generalized wrapping/unwrapping mechanism would be helpful. This could be handled with a new method that offers shortcuts for wrapping/unwrapping selections; some kind of addWrapper(elementName) and removeWrapper(elementName). Anyway, everything we need is actually available in the DOM, except a standardized and simple handling of selections and ranges. (Well, I might be wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, they show very different approaches to the range and selection objects, and the code of TinyMCE shows lots of browser sniffing.) I'd find it very helpful as an addition to Aryeh's work, to get standardized methods for actions like: - creating a range out of a selection - block-extending the range - accessing all child elements of the range - accessing all parent elements of the range - memorizing start and end points in order to reset the selection after modifications (This list may not be complete.) I'd be happy about some thoughts on this. -- Markus
Re: [whatwg] Proposal: content-style attribute for contenteditable elements
Am 19.05.2011 20:39 schrieb Aryeh Gregor: On Tue, May 17, 2011 at 4:09 AM, Markus Ernstderer...@gmx.ch wrote: While discussing about contenteditable elements, the WYSIWYG aspect was mentioned. For real WYSIWYG in a text editor of a CMS, Blog, Forum or whatever, it would be necessary for the contents of the contenteditable element to: - Disable the styles of the surrounding page - Enable the styles of the target page Commonly these are the same, or close to it. If the contenteditable region is part of the UI of a content management system, they are likely to be completely different. In the cases where the styles are really different, it should be fine to require authors to use an iframe. Ok, I see this point.
[whatwg] Editor types [Was: Pressing Enter in contenteditable: p or br or div?]
Am 17.05.2011 22:28 schrieb Ryosuke Niwa:
On Tue, May 17, 2011 at 12:50 PM, Aryeh Gregorsimetrical+...@gmail.comwrote:
On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwarn...@webkit.org wrote:
I completely disagree. As a user, I want semantics when I write my blog
entry on WordPress so that I can tweak presentation afterwards. e.g. I
have
frequently used em {font-style: normal; font-weight:bold;} strong
{text-decoration:underline; font-weight: normal;} in the past.
Then the commands will completely break no matter what you do, because
they're tied to the CSS, not the HTML element. For instance, in this
test case:
No, I apply those CSS styles only on readonly published pages so my editor
isn't affected by those rules.
Re-reading the discussions I get the impression that we have actually
two different basic concepts of online rich-text editors:
1. A WYSIWYG editor. It offers all kinds of formatting options, allowing
users to apply their preferred fonts, colors, sizes, table column widths
and whatever. In this case I want to generate a code that preserves the
visuals in all kinds of situations. In this case, it may be a good idea
to generate style attributes whereever possible. It might even be a good
idea to use divs for paragraph separation, I don't know.
2. An HTML editor. Authors possibly want to restrict the formatting
options. The code generated should be as basic HTML as possible, so the
output adapts to the styles of the target page - even if they are
changed due to a redesign. In this case I want to avoid style attributes
whereever possible, and I definitely want to generate ps and brs. I
might even want to make a distinction between i and em. I assume
this is what Ryosuke (and myself) talk about.
With this distinction in mind, I think some of Aryeh's questions on what
markup we want to generate have two different answers by nature. I read
about the styleWithCSS option erlier in this list. Maybe it would be
helpful to have a more generic option to set the editor into a WYSIWYG
or HTML state. This would of course cause more speccing and
implementation work, but could allow to define two different and
consistent sets of standard behaviors.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 16.05.2011 21:20 schrieb Aryeh Gregor: On Mon, May 16, 2011 at 9:33 AM, Markus Ernstderer...@gmx.ch wrote: I have seen content management systems where text editors tweak the enter key to behave the same also in non-IE UAs (e.g. if you use Contenido with TinyMCE, Firefox produces the same output as IE when you hit enter). I mentioned one forum (vBulletin) which used to set margin to 0 on paragraphs so that IE looked the same as non-IE browsers. So it's an argument for giving authors an option, maybe, but it doesn't help us decide what the default should be. This is very presentational thinking. Correct. This API was designed and is used presentationally, not semantically. Both authors and users want presentational formatting here. That's why it's called What You *See* Is What You Get. Right, but this does not answer the question about the best standard behavior for the enter key. For real WYSIYWYG, it would be necessary to introduce a mechanism to apply some CSS separate from the surrounding page to the contenteditable element, so CMS or forum authors can provide the styles of the output page in the input element. (This is actually the case in iframe-based RTEs such as Kevin Roth's Cross-Browser RTE or TinyMCE.) I assume there are use cases for both generating ps and brs. The IE/Opera approach has the advantage of allowing both, which is perfect for text and basic HTML editing. From a WYSIWYG POV it might be best to offer both options, so authors are not encouraged to add server-side processing to change the output, which would break WYSIWYG. If the behavior is settable, it might even be a good idea to leave the choice of the standard behavior to the UAs. Authors who have a reason to care can set their preferred behavior, while other authors might prefer to leave it as it was, so there is no change for their existing users.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 13.05.2011 12:00 schrieb Michael A. Puls II: On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor simetrical+...@gmail.com wrote: Another problem with p is that it's very easy to create unserializable DOMs with it. I've seen cases where at least some browsers will put things inside p that will break out of the p, and I've done it myself by mistake too. I think the browser/editor just shouldn't allow that in this case. (Not saying that it's easy to enforce it though.) As an author or CMS implementor I'd be happy to see UAs solve this for me, creating a valid sequence of paragraphs. OTOH, if you use divs in order to keep the output serializable, this might lead to kind of messy code. Imagine a content of the contenteditable element like: divdivpFoo/p/div/div divpBar/p/div The user puts the caret to the end of the first line and clicks Enter. With a strict p/br behavior, this is a well-defined action, adding a new paragraph resp. inserting a newline. But if you go with divs, this will possibly mess up the code in a way that is hard to fix (though it is valid and serializable HTML).
[whatwg] Proposal: content-style attribute for contenteditable elements
Hello While discussing about contenteditable elements, the WYSIWYG aspect was mentioned. For real WYSIWYG in a text editor of a CMS, Blog, Forum or whatever, it would be necessary for the contents of the contenteditable element to: - Disable the styles of the surrounding page - Enable the styles of the target page This could be solved with a @content-style attribute which takes a URL pointing to an external stylesheet document. If the attribute is present, all styles of the surrounding page are ignored, and the styles of the linked CSS document are applied to the content of the element. Special cases: - If the linked CSS document contains declarations for the body element, they are applied to the contenteditable element itself. (This could be necessary in case of light text on dark backgrounds, where you want to apply the background to the contenteditable area.) - If there are conflicts between body element styles in the linked stylesheet and the styles of the contenteditable element in the surrounding page, the latter win. (This is necessary to keep the dimensions of the input UI, if an author links the whole CSS of the target page.) Rationale: - In today's iframe-based online rich text editors, it is common to apply the styles of the target page of the edited text to the source document of the iframe. This is not possible in a div contenteditable. - For many use cases, such as forum and blog entries, or non-fullpage oriented web content management systems, div contenteditable is easier to implement than iframe-based editors. The only downside is the WYSIWYG issue. I'd be happy to read some comments on this idea!
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines inp (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter insertsbr.
This is what people know from MS Word, too, and thus it should be
considered as a de-facto standard. I don't have current versions of
other office text editors installed right now, but I assume they will
behave the same, or at least provide a setting to make them behave like
that.
I have seen content management systems where text editors tweak the
enter key to behave the same also in non-IE UAs (e.g. if you use
Contenido with TinyMCE, Firefox produces the same output as IE when you
hit enter).
I'd strongly suggest to spec this behaviour, or at least provide some
kind of setting to force it.
* Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a line when you start typing, but when
you hit Enter it wraps the new line in adiv. Hitting Enter
multiple times outputsdivbr/div, and Shift-Enter always inserts
br.
* Opera 11.10 wraps inp like IE, but for blank lines it uses
pbr/p instead of justp/p (they render the same).
What behavior do we want?
A problem withp is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translatesp and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
This is very presentational thinking. If you write a text, it should be
possible to produce paragraphs by default. If you use div instead of
p, there would be extra coding needed to make paragraphs available.
Another problem withp is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things insidep that will break out of thep,
and I've done it myself by mistake too.
The same applies e.g. for list items, UAs have to solve this problem
anyway. One approach that I could imagine is to close and re-open the
paragraph (resp. list item) at the boundaries of the element which is
put inside it.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 16.05.2011 15:33 schrieb Markus Ernst:
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
A problem withp is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translatesp and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
I am sorry I overread this last sentence when writing my previous
message. I have a swiss-german installation of Word 2007, I did not
change the settings. Hitting enter produces paragraphs here, and applies
the spaces above and/or below that are specified in the paragraph style.
This is the behaviour I have known from Word for years. Maybe there are
regional differences in the defaults of Word.
This is very presentational thinking.
Re-reading my message I am afraid this sentence could be read as an
offense. There was absolutely no offense intended (I am sorry I had to
go pick up my daughter and sent too quickly). I wanted to state that
what CSS people apply should not matter to the question of creating p,
div or br.
The vBulletin example shows that there is a use case for applying br.
I state that there is a use case for applying p for enter and br for
shift-enter.
IMO an ideal solution would provide both (or, if there are use cases for
div, all three) possibilities, settable with a flag or an attribute.
The standard should be what office users expect from their everyday
experience.
Re: [whatwg] Form input element for value-unit pairs
Am 15.03.2011 17:36 schrieb Christoph Päper: Jukka K. Korpela: Christoph Päper wrote: input type=number id=fontsize value=12 unit=pt Or do you mean that the presence of the unit=... attribute would trigger a special implementation of numeric input, so that the user is expected to enter both a number and a unit, with the latter defaulted according to the unit attribute? Yes. UIs may autoconvert the value if the unit changes or keep it. I’m not sure which solution is better. Although the need for number unit input is relatively common, I think it can quite satisfactorily be handled using a number input field and e.g. a dropdown menu of units accepted by an application (or maybe a textfield). After all, processing of the form data would most probably want to split a combined number unit data item into its components, so why put them together in the first place? Usability. Maybe it would work better with ‘datalist’: input name=fontsize type=number unit=typo datalist id=typo option value=2.835 label=pt option value=1 label=mm /datalist I like this approach because it is author configurable and extensible beyond the rich text editor use case. A billing application might apply a list of currencies with appropriate exchange rates for the day. What I do not yet understand is, in what point does this proposal enhance usability compared to a dropdown box with the units, and some client side script that does the conversion?
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Am 13.03.2011 21:46 schrieb Aryeh Gregor: 2) How much work should we go to to produce nice-looking markup? E.g., if the user unbolds baz in div style=font-weight:bold pFoo pBar baz /div should we produce something like div p style=font-weight: boldFoo pbBar/bbaz /div like WebKit does, or would it be okay to do div style=font-weight:bold pFoo pBarspan style=font-weight: normalbaz/span /div to avoid the complexity, given that this sort of markup shouldn't be too common? I think it's clear that something like bFoo baz bar/b should becomebFoo/bbazb bar/b and notbFoo span style='font-weight: normal'baz/span bar/b, but how far should we go? IMO, from the moment you decide to use b and not style=bold (be it due to a user selectable mode or not), style=bold should actually be totally avoided. Thus, the CSS bolding in your example should be replaced by b tags: div pbFoo/b pbBar/b baz /div I think that the code generated should be homogeneous, independent from the original markup (which may be copy-/pasted from various sources). That means, the bolding in your example would be changed to b already when the contenteditable element is built, or when the fragment is pasted in.
[whatwg] Inline list proposal [was: Interpretation issue: can section be used for extended paragraphs?]
Am 10.03.2011 19:18 schrieb Jukka K. Korpela: Markus Ernst wrote: Would it cause serious issues to add the Phrasing Content category to these three elements [ol, ul, dl] thus allowing them inside the p element? I'm afraid it would, and I think that's the reason why the content model hasn't been extended in HTML5. [...] Introducing a new paragraph concept, say par element, would not have this problem, but it would have problems of its own. And the good old p element might feel rather lonely and rejected - and oddly named. I know it is late in the HTML5 process to propose new elements, but please consider this: Instead of a new paragraph concept, there could also be a new concept for inline (resp. Phrasing Content) lists. The concept is actually not too new - for quotes, e.g., we've had both block level blockquote and an inline level q elements for long. Why not the same for lists? Consider this markup of Andy's use case: pI always like to eat these cheeses: il iliCheddar/ili, iliStilton/ili, and iliRed Lester/ili, /il but I enjoy them most with one of these biscuits: il iliwheat crackers/ili, ilirye crackers/ili, ilidigestives/ili, /il and some chutney./p il stands for inline list, ili for inline list item (it's a pity we can't reuse li for BC reasons). Conforming UAs would be required to ignore any content in an il element, except it is in an ili element. Like that, the above example would be perfectly readable in legacy UAs, but make sense in HTML5-capable UAs. It would even be easy to stlye the output for legacy UAs supporting display:list-item, as this example illustrates: http://www.markusernst.ch/stuff_for_the_world/list-test.html I tested this example in FF 3.6, IE 8, Opera 11 and Chrome 9. The unstyled block degrades nicely in all 4 browsers, the styled one is rendered as expected except in IE 8, where it also degrades nicely. I'd be happy to read any thoughts on this.
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
Am 10.03.2011 17:58 schrieb Andy Mabbett: On 10 March 2011 08:20, Jukka K. Korpelajkorp...@cs.tut.fi wrote: what should we say to people to need to use paragraphs that contain lists, for example? This has concerned me for some time. Consider a more complex scenario: pI always like to eat these cheeses:/p ul liCheddar liStilton liRed Lester /ul pbut I enjoy them most with one of these biscuits:/p ul liwheat crackers lirye crackers lidigestives /ul pand some chutney./p What I would like to be able to do is: pI always like to eat these cheeses: ul liCheddar liStilton liRed Lester /ul but I enjoy them most with one of these biscuits: ul liwheat crackers lirye crackers lidigestives /ul and some chutney./p I was annoyed by the exact same issue several times, too. Anyway it looks to me that this problem raised by Jukka Korpela applies mainly to the three list-type elements ol, ul and dl. Would it cause serious issues to add the Phrasing Content category to these three elements, thus allowing them inside the p element? In 3.2.5.1.5 I don't find anything on the expected rendering of Phrasing Content, so I assume UAs would not have to change the default rendering to be conforming. The content model of the li element would have to be added something like only Phrasing Content, if the element is in a context where Phrasing Content is expected. I also don't see serious backwards compatibility breaks, except that the lists of Andy's example would be rendered with top and bottom margins in legacy UAs. (I apologize if this is a silly suggestion for any reason - I can see things only from the author perspective.)
Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
Am 09.03.2011 06:51 schrieb Jukka K. Korpela: Jonas Sicking wrote: I'm having a little bit hard of a time figuring out what a good UI would look like in the general case. I.e. what should the UI look like for input type=date id=date name=date value=2011-04-01 list=datelist exclusive datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th option value=2012-06-06 label=National Day of Sweden /datalist Do you allow flipping between only the months which have any available dates in them using the next/previous month buttons in the date picker? That would be the idea, I guess, but there are two alternatives regarding months that have no applicable days: either skip them or gray them out. So in your example, when in April 2011, Next month button could take you to June 2012, or it might take you to to May 2011 with all days grayed out It should definitely be the latter, as Next month taking you to somewhere else than the next month is confusing. IIRC I have seen JS date pickers behave like that, but I am sorry I don't remember where it was. Even in a rare use case where several months are totally grayed out, the user needs the information that no dates are available there - else (s)he will assume a technical error or somewhat.
Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
Am 09.03.2011 12:19 schrieb Diogo Resende: On Tue, 8 Mar 2011 16:51:25 -0800, Jonas Sicking wrote: On Tue, Mar 8, 2011 at 10:46 AM, Markus Ernst derer...@gmx.ch wrote: Am 08.03.2011 19:02 schrieb Anne van Kesteren: On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist (...) / Jonas I was thinking.. what about allowing big time spans, like: from April 1st to June 30th? Giving that the date has - as date element separators we could not use 1-MM1-DD1-2-MM2-DD2. Couldn't this be useful? Even more common might the usecase where a date must be from some date onward (or until some date). How is this addressed? I assume that this is only a problem if you need to allow/disallow several periods in the same date picker. For one single period, or allowing dates only from or up to some date, you can use min and max attributes in the input type=date element.
Re: [whatwg] Please reconsider: Set restricted palette for input type=color
Am 07.03.2011 18:27 schrieb Markus Ernst: Reading 4.10.7.1.15 on the Color state of the input element, I miss a possibility how to define a set of allowed colors. For other states of the input element there are such possibilities, such as setting min, max and step attributes for input type=date. As UAs are encouraged to provide a user interface, such as a color picker, there should be a way to define a limited set of colors to be included in the picker. Use case: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. Possible solution: Slightly strengthen the impact of the list attribute for this input type. If there is a suggestion source element with one or more valid colors, color pickers are required to only display the colors specified there. Searching for implementations of input type=color, I found that Opera actually implemented the color picker quite similar to my suggestion. If there is a suggestion source element, Opera displays a color palette with the colors listed there, and an Other... button that leads to the detailled color picker. I personnally would like a possibility to hide the Other... button, but this is not really a need. Opera's behaviour makes it possible to provide a consistent validation message, saying something like: Please choose one of the suggested colors. Sorry, other colors are not allowed here. Is it possible to spec Opera's behaviour as a standard for color picking UIs?
[whatwg] Option label, textContent and value
In 4.10.12 on the Option element, the spec states: The label attribute provides a label for element. The label of an option element is the value of the label attribute, if there is one, or the textContent of the element, if there isn't. The value attribute provides a value for element. The value of an option element is the value of the value attribute, if there is one, or the textContent of the element, if there isn't. It looks like this needs clarification for the case both label attribute and text content are present, as UAs do not implement this consistently: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I'd propose to slightly change the specification to treat the value the same, regardless whether it is given in the value attribute or in the text content, and to get the label, where the label attribute is missing, from the value rather than from the text content: The value attribute provides a value for element. The value of an option element is the value of the value attribute, if there is one, or the textContent of the element, if there isn't. The label attribute provides a label for element. The label of an option element is the value of the label attribute, if there is one, or the value of the element, if there isn't.
Re: [whatwg] Option label, textContent and value
Am 08.03.2011 15:22 schrieb Jukka K. Korpela: Markus Ernst wrote: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. This is a bug in Firefox. The label attribute is defined for option even in HTML 4.01, though its use has been limited - it was mainly introduced for use in nested menus, where an option is inside optgroup Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select Yes, that has been the case since HTML 2. But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I'm not sure I follow you here... The idea is that a datalist element has no text content, i.e. all information is in the attributes of its children. If you had some content in the option element, then it would be visible on browsers that do not understand the datalist markup. Yes... all I meant was actually that I would consider it consistent if both select optionfoo /select datalist option value=foo /datalist work the same regarding the label. According to the current spec, the option in the select element has a label foo, while the one in the datalist element has none. With the change I proposed, both would have the label foo.
[whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
Am 08.03.2011 19:02 schrieb Anne van Kesteren: On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist This is currently conforming, though no browser seems to make use of the datalist. A good implementation would open up a calendar for April, with only days 1, 8, 9 selectable and day 1 highlighted. Many existing applications use such interfaces, so there is apparent need for them. Agreed that we should fix this, but note that datalist is for additional or pre-suggested options. The idea is that the user still has choice so the other days should be selectable too. Which means in the mentioned use case, that the user can select a date when no flight is actually available. We can of course validate the input and ask the user to select another date, but still this results in sub-optimal user experience (and extra JS code). The exclusive attribute suggested by Jukka K. Korpela for the datalist element would change this behaviour, making unavailable options unselectable. I hope very much that this proposal will make it into the standard. Except for date/time and color input elements, I can also imagine use cases regarding the range element (if a part of the range is not available).
[whatwg] Please reconsider: Set restricted palette for input type=color
Reading 4.10.7.1.15 on the Color state of the input element, I miss a possibility how to define a set of allowed colors. For other states of the input element there are such possibilities, such as setting min, max and step attributes for input type=date. As UAs are encouraged to provide a user interface, such as a color picker, there should be a way to define a limited set of colors to be included in the picker. Use case: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. Possible solution: Slightly strengthen the impact of the list attribute for this input type. If there is a suggestion source element with one or more valid colors, color pickers are required to only display the colors specified there. Rationale: While searching the list archives, I found a message from Ian Hickson: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017482.html He suggested to use a select element for the purpose of a restricted color set. Here's why I think it would be worth to reconsider this position: - A select element would display color names or values instead of showing the colors, which does not make it a suitable UI for choosing colors. - Restricting the color palette is actually almost as common a task, as defining start and end dates of a date picker, and for sure more common than defining a step in a date picker. Now we have the benefit of this specialized color input element, it is a pity if it lacks customization potential. - The fact that most CMS do not have restricted color sets so far, does not mean there is no demand for it, but rather shows the difficulty of customizing tools such as TinyMCE. It is a hassle for CMS implementors (who are often not highly skilled JS programmers), if they are expected to respect corporate design guidelines. - I assume that restricting a color set in an existing color picker is not too hard to implement (of course I have no evidence for this assumption).
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Am 01.03.2011 19:36 schrieb Aryeh Gregor: Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early review comments on the direction I'm taking, particularly from implementers but also from anyone else familiar with the APIs (e.g., someone who's used them in practice): http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD The plan is that this should be merged into the main HTML spec, with a full test suite, by the end of August. Feedback appreciated. I am very interested in your work because I work with content management systems a lot. Some months ago I started to write a simple rich text editor trying to use DOM methods instead of execCommand(), because I don't like the the code some UAs produce, and wanted a slim and easily configurable editor. If execCommand() gets standardized and enhanced, I might be happy to abandon the project. Here are a few comments from my point of view: - I assume that the list of commands is not complete, as some commands given in the HTML spec are missing, such as formatBlock or insertHTML - or is it your intention to drop these commands? For better understanding, it might be worth to clarify this. - Please consider adding a generic formatInline command for applying all kinds of inline elements. A sophisticated RTE might e.g. want to provide separate bold and strong options for authors caring about this distinction. - I'd like a className command to be added. Corporate websites usually use a restricted set of formattings; in a CMS for such a website it should be possible to provide a select box with the respective CSS classes rather than font and color menus. - In the opposite case, where everything is allowed, users might want to apply CSS properties not covered by the command list, such as borders, or future fancy stuff such as shadows. For these cases, an applyCSS command could be helpful. - Some CMS systems use different doctypes than the pages where the edited text is finally published. Content edited in an HTML5 page might be published in an XHTML page. While it is not too complicated to solve this in practice with server-side string editing - would it be possible to specify the desired HTML style for the output? (Which could result in different HTML styles in a contenteditable area and the surrounding document.) These are just some thoughts out of my everyday work, of course I have no idea about implementation cost and whatever issues. Generally, I think that a future-proof execCommand() specification should rather provide generic commands for inline and CSS formatting, and support specific commands such as bold or backColor only for backwards compatibility reasons. (This would also make a discussion on the preference of element or CSS formatting obsolete, as RTE authors would have the choice to use either.)
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Am 03.03.2011 20:53 schrieb Aryeh Gregor: I get the hand-editing argument.b is much nicer to hand-edit than span style=font-weight: bold, and also fewer bytes. But why would anyone wantspan style=font-weight: bold? pbText/b/p is even fewer bytes and more readable than p style=font-weight:boldText/p. So if you don't want to leave the choice to RTE authors I'd vote for element formatting where available.
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Am 04.03.2011 19:58 schrieb Aryeh Gregor: 2) In CSS mode, use CSS where the tag isn't conforming (font, etc.) or there is no tag (like hiliteColor). 3) In non-CSS mode, use tags where available even if not conforming (font, etc.), and only use CSS if there's no tag for the feature (like hiliteColor). May I propose to call the modes something like standards mode and legacy mode - as an author unaware of the backgrounds, I would not expect a non-CSS mode output font tags - it would drive me crazy.
Re: [whatwg] wrapper element
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.: I believe you're arguing that the wrapper semantic, being similarly ubiquitous, thus needs its own new element as well. What you're missing is that the wrapper semantic is precisely whatdiv already expresses. I do understand usuario's wrapper proposal slightly different from div: Section 4.5.13 of the spec generally states that the div element is conveying structure, but not semantics. Usuario's wrapper is not structural, but purely presentational. It should actually not be there at all from an HTML point of view, but is necessary for CSS reasons. I agree with Bjartur Thorlacius' point that it makes more sense to enhance CSS the way that presentational markup gets totally obsolete in the future - but the idea of an element that is explicitly non-structural does not look that odd to me.
Re: [whatwg] wrapper element
Am 01.03.2011 23:50 schrieb Jordan Dobson:
On Tue, Mar 1, 2011 at 2:03 PM, Markus Ernstderer...@gmx.ch wrote:
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.:
I believe you're arguing that the wrapper semantic, being similarly
ubiquitous, thus needs its own new element as well. What you're
missing is that the wrapper semantic is precisely whatdiv already
expresses.
I do understand usuario'swrapper proposal slightly different fromdiv:
Section 4.5.13 of the spec generally states that thediv element is
conveying structure, but not semantics.
Usuario'swrapper is not structural, but purely presentational. It should
actually not be there at all from an HTML point of view, but is necessary
for CSS reasons.
Isn't that what the section::outside{ ... } is for? Presentational pseudo
elements in CSS?
http://www.w3.org/TR/css3-content/#wrapping
Granted it's not available as far as I know... but it seems like it meets
usario's needs.
::outside covers only a part of the use cases for wrapping elements -
wrapper containing more than one child elements cannot be replaced by
::outside - consider the very common case of a centered page:
body
div id=container
header/header
nav/nav
div id=contents/div
footer/footer
/div
/body
#container { margin:0 auto; width:50em; position:relative }
#contents { margin-left:10em }
nav{ position:absolute; top:50px; left:0; width:9em }
This case would require some kind of body::inside pseudo element, which
I cannot find in the CSS3 Generated and Replaced Content Module spec
right now. (Well, sorry if I get too much off-topic now.)
[whatwg] Stop control for video [was: Limiting the amount of downloaded but not watched video]
Am 18.01.2011 18:11 schrieb Zachary Ozer: Currently, there's no way to stop / limit the browser from buffering - once you hit play, you start downloading and don't stop until the resource is completely loaded. This is largely the same as Flash, save the fact that some browsers don't respect the preload attribute. (Side note: I also haven't found a browser that stops loading the resource even if you destroy the video tag.) There has been a version of JWplayer with a stop control (as I suggested earlier in this thread for the user aspect of the topic). I set up a demo page: http://www.markusernst.ch/stuff_for_the_world/jwplayertest.html If you click the stop button, playback is stopped, and the status bar disappears. If you click the play button again, playback is started from the beginning, and the status bar shows download being continued from the point where the stop button has been clicked. So this player seems to interrupt the download and resume it, when playback is restarted. This looks like an intuitive and sensible behaviour to me, which could both improve user experience and save server bandwidth. It could be implemented independent from, and additionnally to the points discussed in the original thread.
Re: [whatwg] Limiting the amount of downloaded but not watched video
Am 17.01.2011 17:41 schrieb Jeroen Wijering: Hello all, We are getting some questions from JW Player users that HTML5 video is quite wasteful on bandwidth for longer videos (think 10min+). This because browsers download the entire movie once playback starts, regardless of whether a user pauses the player. If throttling is used, it seems very conservative, which means a lot of unwatched video is in the buffer when a user unloads a video. I did a simple test with a 10 minute video: playing it; pausing after 30 seconds and checking download progress after another 30 seconds. With all browsers (Firefox 4, Safari 5, Chrome 8, Opera 11, iOS 4.2), the video would indeed be fully downloaded after 60 seconds. Some throttling seems to be applied by Safari / iOS, but this could also be bandwidth fluctuations on my side. Either way, all browsers downloaded the 10min video while only 30 seconds were being watched. The HTML5 spec is a bit generic on this topic, allowing mechanisms such as stalling and throttling but not requiring them, or prescribing a scripting interface: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource Are there people working on ways to trim down the amount of not-watched data for video playback? Any ideas on this, anything in the pipeline? --- A suggestion would be to implement / expose a property called downloadBufferTarget. It would be the amount of video in seconds the browser tries to keep in the download buffer. When a user starts (or seeks in) a video, the browser would try to download downloadBufferTarget amount in seconds of video. When downloaded currentTime + downloadBufferTarget, downloading would get stalled, until a certain lower treshold is reached (e.g. 50%) and the browser would start downloading additional data. A good default value for downloadBufferTarget would be 60 seconds. Webdevelopers who have short clips / do not care about downloads can set downloadBufferTarget to a higher value (e.g. 300). Webdevelopers who have long videos (15min+) / want to keep their bandwidth bill low can set downloadBufferTarget to a lower value (e.g. 15). Webdevelopers might even change the value of downloadBufferTarget per visitor; visitors with little bandwidth get a sizeable buffer (to prevent stuttering) and visitors with a big pipe get a small download buffer (they don't need it). Could this be done at the user side, e.g. with some browser setting? Or even by a stop downloading control in the player? An intuitive user control would be separate stop and pause buttons, as we know them from tape and CD players. Pause would then behave as it does now, while stop would cancel downloading. This would be helpful, as there are various viewing situations, that are not under control of the web developer: 1. Start playback, pause, do something else and wait until the movie is downloaded (the case Boris Zbarski mentioned) 2. On a page with multiple movies, such as a Myspace profile of a musician, you start playback of a movie, pause it to see the next one, pause it to see the third one... and soon you have several movies downloading, instead of only the last one you really want to see at the moment. While in situation 1 the download buffer would be a hassle, it would be helpful in situation 2. Separate pause and stop controls would help in both cases.
Re: [whatwg] sic element, was: Re: Exposing spelling/grammar suggestions in contentEditable
Am 31.12.2010 17:30 schrieb Benjamin Hawkes-Lewis: On Fri, Dec 31, 2010 at 3:17 PM, Martin Janeckewhatwg@kaor.in wrote: [snip] Apart from informing human readers about the correct reproduction of a misspelled word, a HTMLsic would indicate the same to web applications. Think of a search engine, which, as one factor of their ranking algorithm, considers orthography and grammar in a page as quality factor. The search engine could be made to ignore (reasonably few)sic-marked errors in such an algorithm; i.e. not letsic-marked errors rank the page lower. Would search engines benefit from markup for this? They could actually benefit, if the correct spelling would be added in an attribute, so they could match the misspelled word with a correctly spelled search term; somehow like: sic correct=choosechuse/sic This would probably lead to abuse by seo trickers: sic correct=pornbuy/sic sic correct=sexmy product!/sic Also, I assume that this search engine benefit can already be achieved with existing markup: span title=choosechuse/span
Re: [whatwg] Proposal for a tab visibility API
Am 09.12.2010 00:12 schrieb Boris Zbarsky: On 12/8/10 5:29 PM, Markus Ernst wrote: Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value). This is pretty hard to implement, in general. For example, if I put another window over the browser window then whether the content in the browser is visible depends on the exact app running in that window, and on the parts of it overlapping the browser content, right? Sure. Some applications might even be partially transparent, like some fancy-skinned media players.
Re: [whatwg] Proposal for a tab visibility API
Am 09.12.2010 07:12 schrieb Boris Zbarsky: 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. I'd really appreciate some comment on this. I'm pretty worried about adding features that we then have to start working around people abusing almost immediately... I assume that the abuse potential here is about the same as for onunload. Regarding ads, I assume that providing some kind of visibility API could also lead to better ads. Ad authors could make their ads stop executing when invisible. One main annoyance about ads is their resource consumption, thus ad blockers could provide a setting Block content from ad providers who don't stop the execution of hidden ads. Which would allow their users to block annoying resource consumers, while not blocking good ads, which their favorite websites might depend on.
Re: [whatwg] Proposal for a tab visibility API
Am 08.12.2010 21:40 schrieb Bjartur Thorlacius: On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, Minor semantic nitpick: please use the term /does not have focus/ rather than /is a background tab/, as the latter is misleading in window managers that don't use tabs to represent (all) windows. [Ninja'd] I am not too much familiar with the terminology here, but I humbly think that not having focus does not necessarily mean a window is not visible. I often have more than one visible window; maybe one where I am currently working, and another one at the side with a football game streamed or whatever. I wouldn't like the football stream to be stopped when this window looses focus. But when the stream gets totally hidden, be it that I open a new tab in the same window, or place some other window in front of it, the streaming application might want to save bandwidth by pausing the streaming of the visuals, while streaming on the audio. Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value).
Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable
Am 28.11.2010 17:27 schrieb Adrian Sutton: On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote: On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton adrian.sut...@ephox.com mailto:adrian.sut...@ephox.com wrote: User's expect a rich text editor to override the browser default context menu to provide things like properties for images, lists, tables etc and the other stuff usually found in a rich text editor's context menu. However, once that is done, the browser's built-in spelling suggestions are no longer available, effectively losing support for inline spell checking. The user agent may also provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus It could, but it doesn't. Any browser that tried doing that would likely just run into compatibility complaints and have to revert it. More importantly, there's no way to instruct or even suggest that the browser should which leaves users without functioning spell checking and rich text authors with no way to meet the demands of users. This looks like a context menu problem to me, not a spell-checking problem. There are more occasions where an overridden context menu in script-driven parts of a webpage is annoying, e.g. it is impossible to use print preview or back on a google map. So, solving the context-menu issue might be a boost for a browser vendor.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Am 25.11.2010 13:21 schrieb Biju: On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Modal dialogues have a very special purpose, which works consistently across various browsers in that we can program in with javascript some very specific responses. What would happen if someone came to your site with a speech/Braille browser? How would they know your pretty js lib built That is a valid point. But how many good sites use alert/confirm/prompt for every thing. So all those case speech/Braille browser have problem to deal with. If we want use that feature the web site need to code their site for speech/Braille browser. If that is the case we could achieve same thing with HTML. Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Am 25.11.2010 17:12 schrieb Nikita Popov: On 25.11.2010 15:55, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. Sorry, that was how I understood point 1 your initial message. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. Well, you just said it: Bug 59314! That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside).
Re: [whatwg] Iframe dimensions
Am 16.11.2010 00:32 schrieb Ian Hickson: On Wed, 11 Aug 2010, Markus Ernst wrote: Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: [...] Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is under construction.) As a workaround to the height problem, I applied a script that adjusts the iframe height to the available height in the browser window. But of course the user experience would be more consistent if the page could behave like a single page, with only one scrollbar at the right of the browser window. If you control both pages and can't use seamless, you can use postMessage() to negotiate a size. On the long term, I expect we'll make seamless work with CORS somehow. I'm waiting until we properly understand how CORS is used in the wild before adding it all over the place in HTML. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.:meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. On Wed, 11 Aug 2010, Adam Barth wrote: That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? On Wed, 11 Aug 2010, Anne van Kesteren wrote: What exactly is hard about it? (Though I should note we should carefully study whether using CORS here is safe and sound. For instance, you may want to allow seamless embedding, but not share content.) I'd like to echo Anne's comments. If CORS is hard, then we should change that; if it's not, then we should use it (once we know it's solid). I tried to understand the CORS spec, but with no real knowledge about networking basics this is quite hard. Anyway it is not necessary for authors to understand the spec, as there will be how-tos available of course. From my humble author's POV, CORS is easy enough for tasks like the one I mentioned, if: - it is applicable at the server side with common scripting languages such as PHP - it is applicable at the client side without scripting
Re: [whatwg] Iframe dimensions
Am 16.11.2010 19:12 schrieb Tab Atkins Jr.: On Tue, Nov 16, 2010 at 10:06 AM, Boris Zbarskybzbar...@mit.edu wrote: On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? Ah, if that's what Markus was getting at, then yes. CORS requires *zero* work on the client side, since it's completely done in the server-browser interaction. The entirety of the client's interaction in the process is the initial request for a resource. That is great news. Adding a header via a server-side script is indeed easy enough. (As I did not find any HTML attributes or whatever in the CORS spec, I was afraid that the use of XHR would be necessary to call a cross-origin page in an Iframe - which looked like a huge overhead and also an accessibility issue to me.)
Re: [whatwg] time element feedback
Am 31.08.2010 22:21 schrieb Martin Janecke: Am 31.08.10 21:40, schrieb Aryeh Gregor: On Tue, Aug 31, 2010 at 5:25 AM, Martin Janeckewhatwg@kaor.in wrote: Besides,time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though. I understand your point, the situation you describe would be unfavorable indeed. However, there's no need to make this unfavorable. The localized display of times and dates can be realized via tooltips for example, as it is often seen with abbreviations in texts. The localized date doesn't have to be a replacement for the original date string but can be a helpful, explaining addition. This is a nice idea, but localisation should then be based on the language of the context of the time element, not based on the browser language: html lang=de body pDie Party ist time datetime=2010-09-01heute/time./p /body /html The tooltip might then display 1. September 2010 in German - independent from the computer or browser language. As Aryeh stated, displaying a Japanese or English date here on the computer in an internet café would be highly disturbing - even in a tooltip. Localisation should not mess around with the content unless explicitly triggered by the author. -- Markus
Re: [whatwg] Proposal: Add HTMLElement.innerText
Am 16.08.2010 11:23 schrieb Maciej Stachowiak: - Is it a genuinely useful feature? Yes, the ability to get plaintext content as rendered is a useful feature and annoying to implement from scratch. To give one very marginal data point, it's used by our regression text framework to output the plaintext version of a page, for tests where layout is irrelevant. A more hypothetical use would be a rich text editor that has a convert to plaintext feature. textContent is not as useful for these use cases, since it doesn't handle line breaks and unrendered whitespace properly. Additionnally, from a humble author's POV, once you learnt that innerHTML is now available in the standard, it would be quite intuitive to also have innerText.
Re: [whatwg] Iframe dimensions
Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: [...] Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is under construction.) As a workaround to the height problem, I applied a script that adjusts the iframe height to the available height in the browser window. But of course the user experience would be more consistent if the page could behave like a single page, with only one scrollbar at the right of the browser window. If you control both pages and can't use seamless, you can use postMessage() to negotiate a size. On the long term, I expect we'll make seamless work with CORS somehow. I'm waiting until we properly understand how CORS is used in the wild before adding it all over the place in HTML. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.: meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. On Tue, 6 Jul 2010, Markus Ernst wrote: My problem is this sentence in the spec for seamless: This will cause links to open in the parent browsing context. In an application like http://test.rapid.ch/de/haendler-schweiz/iseki.html, the external page should be able to re-call itself inside the iframe, for example if a sort link is clicked or a search form submitted. On Tue, 6 Jul 2010, Ashley Sheridan wrote: Could you explicitly call the _self target in links in the frame? I wasn't sure if the target attribute was going or not, but I'd expect target=_self to override the default seamless action. Good point. Fixed. You can now work around this by targetting the frame explicitly using base target=_self. (Or by using target=foo if the iframe has name=foo.) Great!
[whatwg] Proposal for an addition to the authoring guidance regarding the alt attribute
Section 4.8.1.1.9 describes how alternative text for content images should be written: http://www.w3.org/TR/html5/embedded-content-1.html#a-key-part-of-the-content Then, there is a general guideline about writing alternative texts in section 4.8.1.1.12: A corollary to this is that the alt attribute's value should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image. The title attribute can be used for supplemental information. IMO the wording of 4.8.1.1.9 is somehow contradictive to the general guidance in two cases: 1. The image is the information itself, it does not convey any information beyond it's visuals. This is a very common case, for example in photo galleries. Unlike the examples given under The general case (where lack of the image is lack of information), the images in a wedding photo gallery cannot be described in a way that matches 4.8.1.1.12 and provides any useful information for e.g. a blind user. The information Me, Gary, and his parents eating the cake is rather useful for those who actually see the image, and should go to the caption, as correctly stated in 4.8.1.1.12. 2. The image illustrates what is discussed in the surrounding text, or has a caption describing it. Inserting alt text would actually duplicate the information, but not convey anything useful for those who don't see the image. IMO alternative text should be omitted in this case (as e.g. Wikipedia does: http://en.wikipedia.org/wiki/Squirrel - the alt attribute values of all content images are empty). So I propose to: - Explicitly treat these two cases in 4.8.1.1.9, requiring to insert no alt text there - In the part Images whose contents are not known, remove the word unfortunate at the beginning (In some cases), and the first note. (Apparently, the W3C itself is not so sure about alt text in content images; http://www.w3.org/Consortium/mission illustrates this: There is a picture of Tim Berners-Lee, with no direct reference in the text. It does not seem to be decorative, as according to 4.8.1.1.6 the alt attribute should be empty in this case; but the alt text says: Tim Berners-Lee speaking at W3C10, which is not an information conveyed by the image itself if you don't know how Tim Berners-Lee looks like. Thus, according to 4.8.1.1.9, this information should be displayed in a caption, and the alt attribute should say something like A male speaker in front of a display containing the text 'W3C10 Tenth Anniversary' and some sponsor logos - which is of course stupid. The empty string would IMO be the appropriate value for the alt attribute here.)
Re: [whatwg] Content-Disposition property for a tags
Am 02.08.2010 18:21 schrieb Michael Kozakewich: Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Maybe it would do if the type was set to application/octet-stream, since those, by default, always get downloaded. People don't often like it when they're forced to do something. If they want to download it, they can select Save Link As... from their browser. If they actually want to view it full-screen, they don't want to be forced to download it. I see where you're coming from, but we try not to force users to do things. For the same reason, @target was removed from links. But it has made it back into HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element I assume the reason is that some de-facto standards have established that users have got used to. One of them seems to be that clicking on an external link in a corporate web site usually opens a new window or tab, whatever they set in their browser prefs. Some users (like me) might forget to hold the ctrl key because most corporate websites use target=_blank anyway on all external links, and get annoyed if the original page disappears and they have to go back their session history. Another de-facto expectation could be, that on a download page with several links, they behave consistently, starting a download: h1Press downloads/h1 ul lia href=portrait.jpgPortrait image (JPG)/a/li lia href=band-photo.tifMy band (TIFF)/a/li lia href=cv.pdfCurriculum vitae (PDF)/a/li lia href=discography.xlsDiscography (Excel File)/a/li /ul Every link is likely to invoke an other default action, which does not seem consistent to me in this context - even if the downloading journalist as an experienced user might be able to anticipate the action based on the file type information in the brackets. Dennis' and Roger's proposal would definitely be helpful here.
Re: [whatwg] Please consider simplifying authoring guidance for the img alt attribute
Am 01.08.2010 11:43 schrieb Tantek Çelik: http://wiki.whatwg.org/wiki/Img_Alt I encourage fellow web authors to add opinions/comments. My personal opinion on the alt attribute is that: - it should only be used if the image is crucial for understanding the content, or for navigation (such as headline or link images or charts) - it's absence should default to what is alt= in HTML4 - search engines should generally ignore text in the alt attribute, but evaluate the title attribute instead Rationale: 4.8.1.1.12 says: A corollary to this is that the alt attribute's value should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image. The title attribute can be used for supplemental information. The most common use cases of @alt are (at least as far as I know from my authoring practise): - Insert the text contained in a headline or link image - Insert an empty string to make the page validate - Insert a short description of the image, preferably containing some keywords for search engines; sometimes the search engine aspect is weighted even higher than the contents of the image here Only the first one of these use cases matches the gideline given in 4.8.1.1.12. The second one is not harmful, exept some minimal bandwidth impact. But the third one is actually counterproductive with regard to accessibility. An image which conveys information, if it is not a text replacement (such as a headline or link image), a corporate logo, or some kind of chart, is usually almost impossible to describe in a way that can't be considered the image's caption, title, or legend. Usually, the information conveyed by the image is either duplicated in the text that the image is associated to (or in it's caption or legend), or at all useless for anybody that does not see the image. Either way, the presence of an alt text does not provide useful information, but possibly confuses - specially if it is written with regard to search engines. I am confident that declaring the alt attribute as optional would not only simplify the spec and validation, but also have no significant effect regarding accessibility, as poor authoring cannot really be prevented by structural means. And I am also confident that if search engines ignored the alt attribute, and authors were encouraged to only insert alt text if helps to understand the content, this would have a positive effect on accessibility, as authors would be discouraged to put unnecessary information in the alt attribute for seo purposes, or duplicate the legend or caption (what I used to do before I read 4.8.1.1.12, because HTML4 seemed to require exactly this).
Re: [whatwg] Iframe dimensions
Am 06.07.2010 22:41 schrieb Ashley Sheridan: On Tue, 2010-07-06 at 16:17 -0400, Aryeh Gregor wrote: On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst derer...@gmx.ch mailto:derer...@gmx.ch wrote: My problem is this sentence in the spec for seamless: This will cause links to open in the parent browsing context. In an application like http://test.rapid.ch/de/haendler-schweiz/iseki.html, the external page should be able to re-call itself inside the iframe, for example if a sort link is clicked or a search form submitted. Oh. Hmm. That does seem to pose a problem. I can't think of any good solutions off the top of my head. Could you explicitly call the _self target in links in the frame? I wasn't sure if the target attribute was going or not, but I'd expect target=_self to override the default seamless action. This looks consistent to me. To clarify it, the first list item in the part on @seamless in 4.8.2 could then be extended somehow like: o The user agent must set the seamless browsing context flag to true for that browsing context. This will cause links to open in the parent browsing context, unless they contain a target attribute which explicitly specifies another link target. (I assume, links also refers to form actions here.)
